home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1077 < prev    next >
Text File  |  1995-07-25  |  114KB  |  2,580 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                              Gigabit Working Group
  8. Request for Comments: 1077                             B. Leiner, Editor
  9.                                                            November 1988
  10.  
  11.  
  12.               Critical Issues in High Bandwidth Networking
  13.  
  14.  
  15. Status of this Memo
  16.  
  17.    This memo presents the results of a working group on High Bandwidth
  18.    Networking.  This RFC is for your information and you are encouraged
  19.    to comment on the issues presented.  Distribution of this memo is
  20.    unlimited.
  21.  
  22. ABSTRACT
  23.  
  24.    At the request of Maj. Mark Pullen and Maj. Brian Boesch of DARPA, an
  25.    ad-hoc working group was assembled to develop a set of
  26.    recommendations on the research required to achieve a ubiquitous
  27.    high-bandwidth network as discussed in the FCCSET recommendations for
  28.    Phase III.
  29.  
  30.    This report outlines a set of research topics aimed at providing the
  31.    technology base for an interconnected set of networks that can
  32.    provide highbandwidth capabilities.  The suggested research focus
  33.    draws upon ongoing research and augments it with basic and applied
  34.    components.  The major activities are the development and
  35.    demonstration of a gigabit backbone network, the development and
  36.    demonstration of an interconnected set of networks with gigabit
  37.    throughput and appropriate management techniques, and the development
  38.    and demonstration of the required overall architecture that allows
  39.    users to gain access to such high bandwidth.
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Gigabit Working Group                                           [Page 1]
  59.  
  60. RFC 1077                                                   November 1988
  61.  
  62.  
  63.    1.  Introduction and Summary
  64.  
  65.  
  66.  
  67.    1.1.  Background
  68.  
  69.  
  70.    The computer communications world is evolving toward both high-
  71.    bandwidth capability and high-bandwidth requirements.  The recent
  72.    workshop conducted under the auspices of the FCCSET Committee on High
  73.    Performance Computing [1] identified a number of areas where
  74.    extremely high-bandwidth networking is required to support the
  75.    scientific research community.  These areas range from remote
  76.    graphical visualization of supercomputer results through the movement
  77.    of high rate sensor data from space to the ground-based scientific
  78.    investigator.  Similar requirements exist for other applications,
  79.    such as military command and control (C2) where there is a need to
  80.    quickly access and act on data obtained from real-time sensors.  The
  81.    workshop identified requirements for switched high-bandwidth service
  82.    in excess of 300 Mbit/s to a single user, and the need to support
  83.    service in the range of a Mbit/s on a low-duty-cycle basis to
  84.    millions of researchers.  When added to the needs of the military and
  85.    commercial users, the aggregate requirement for communications
  86.    service adds up to many billions of bits per second.  The results of
  87.    this workshop were incorporated into a report by the FCCSET [2].
  88.  
  89.    Fortunately, technology is also moving rapidly.  Even today, the
  90.    installed base of fiber optics communications allows us to consider
  91.    aggregate bandwidths in the range of Gbit/s and beyond to limited
  92.    geographical regions.  Estimates arrived at in the workshop lead one
  93.    to believe that there will be available raw bandwidth approaching
  94.    terabits per second.
  95.  
  96.    The critical question to be addressed is how this raw bandwidth can
  97.    be used to satisfy the requirements identified in the workshop: 1)
  98.    provide bandwidth on the order of several Gbit/s to individual users,
  99.    and 2) provide modest bandwidth on the order of several Mbit/s to a
  100.    large number of users in a cost-effective manner through the
  101.    aggregation of their traffic.
  102.  
  103.    Through its research funding, the Defense Advanced Research Projects
  104.    Agency (DARPA) has played a central role in the development of
  105.    packet-oriented communications, which has been of tremendous benefit
  106.    to the U.S. military in terms of survivability and interoperability.
  107.    DARPA-funded research has resulted in the ARPANET, the first packet-
  108.    switched network; the SATNET, MATNET and Wideband Network, which
  109.    demonstrated the efficient utilization of shared-access satellite
  110.    channels for communications between geographically diverse sites;
  111.  
  112.  
  113.  
  114. Gigabit Working Group                                           [Page 2]
  115.  
  116. RFC 1077                                                   November 1988
  117.  
  118.  
  119.    packet radio networks for mobile tactical environments; the Internet
  120.    and TCP/IP protocols for interconnection and interoperability between
  121.    heterogeneous networks and computer systems; the development of
  122.    electronic mail; and many advances in the areas of network security,
  123.    privacy, authentication and access control for distributed computing
  124.    environments.  Recognizing DARPA's past accomplishments and its
  125.    desire to continue to take a leading role in addressing these issues,
  126.    this document provides a recommendation for research topics in
  127.    gigabit networking.  It is meant to be an organized compendium of the
  128.    critical research issues to be addressed in developing the technology
  129.    base needed for such a high bandwidth ubiquitous network.
  130.  
  131.  
  132.    1.2.  Ongoing Activities
  133.  
  134.  
  135.    The OSTP report referred to above recommended a three-phase approach
  136.    to achieving the required high-bandwidth networking for the
  137.    scientific and research community.  Some of this work is now well
  138.    underway.  An ad-hoc committee, the Federal Research Internet
  139.    Coordinating Committee (FRICC) is coordinating the interconnection of
  140.    the current wide area networking systems in the government; notably
  141.    those of DARPA, Department of Energy (DoE), National Science
  142.    Foundation (NSF), National Aeronautics and Space Administration
  143.    (NASA), and the Department of Health and Human Services (HHS).  In
  144.    accordance with Phases I and II of the OSTP report, this activity
  145.    will provide for an interconnected set of networks to support
  146.    research and other scholarly pursuits, and provide a basis for future
  147.    networking for this community.  The networking is being upgraded
  148.    through shared increased bandwidth (current plans are to share a 45
  149.    Mbit/s backbone) and coordinated interconnection with the rest of the
  150.    world.  In particular, the FRICC is working with the European
  151.    networking community under the auspices of another ad-hoc group, the
  152.    Coordinating Committee for Intercontinental Research Networks
  153.    (CCIRN), to establish effective US-Europe networking.
  154.  
  155.    However, as the OSTP recommendations note, the required bandwidth for
  156.    the future is well beyond currently planned public, private, and
  157.    government networks.  Achieving the required gigabit networking
  158.    capabilities will require a strong research activity.  There is
  159.    considerable ongoing research in relevant areas that can be drawn
  160.    upon; particularly in the areas of high-bandwidth communication
  161.    links, high-speed computer switching, and high-bandwidth local area
  162.    networks.  Appendix A provides some pointers to current research
  163.    efforts.
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Gigabit Working Group                                           [Page 3]
  171.  
  172. RFC 1077                                                   November 1988
  173.  
  174.  
  175.    1.3.  Document Overview
  176.  
  177.  
  178.    This report outlines a set of research topics aimed at providing the
  179.    technology base for an interconnected set of networks that can
  180.    provide the required high-bandwidth capabilities discussed above.
  181.    The suggested research focus draws upon ongoing research and augments
  182.    it with basic and applied components.  The major activities are the
  183.    development and demonstration of a Gigabit Backbone network (GB) [3],
  184.    the development and demonstration of an interconnected set of
  185.    networks with gigabit throughput and appropriate management
  186.    techniques, and the development and demonstration of the required
  187.    overall architecture that allows users to gain access to such high
  188.    bandwidth.  Section 2 discusses functional and performance goals
  189.    along with the anticipated benefits to the ultimate users of such a
  190.    system.  Section 3 provides the discussion of the critical research
  191.    issues needed to achieve these goals.  It is organized into the major
  192.    areas of technology that need to be addressed: general architectural
  193.    issues, high-bandwidth switching, high-bandwidth host interfaces,
  194.    network management algorithms, and network services.  The discussion
  195.    in some cases contains examples of ongoing relevant research or
  196.    potential approaches.  These examples are intended to clarify the
  197.    issues and not to propose that particular approach.  A discussion of
  198.    the relationship of the suggested research to other ongoing
  199.    activities and optimal methods for pursuing this research is provided
  200.    in Section 4.
  201.  
  202.  
  203.    2.  Functional and Performance Goals
  204.  
  205.  
  206.    In this section, we provide an assessment of the types of services a
  207.    GN (four or five orders of magnitude faster than the current
  208.    networks) should provide to its users.  In instances where we felt
  209.    there would be a significant impact on performance, we have provided
  210.    an estimate of the amount of bandwidth needed and delay allowable to
  211.    provide these services.
  212.  
  213.  
  214.    2.1.  Networking Application Support
  215.  
  216.  
  217.    It is envisioned that the GN will be capable of supporting all of the
  218.    following types of networking applications.
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Gigabit Working Group                                           [Page 4]
  227.  
  228. RFC 1077                                                   November 1988
  229.  
  230.  
  231.    Currently Provided Packet Services
  232.  
  233.       It is important that the network provide the users with the
  234.       equivalent of services that are already available in packet-
  235.       switched networks, such as interactive data exchange, mail
  236.       service, file transfer, on-line access to remote computing
  237.       resources, etc., and allow them to expand to other more advanced
  238.       services to meet their needs as they become available.
  239.  
  240.    Multi-Media Mail
  241.  
  242.       This capability will allow users to take advantage of different
  243.       media types (e.g., graphics, images, voice, and video as well as
  244.       text and computer data) in the transfer of messages, thereby
  245.       increasing the effectiveness of message exchange.
  246.  
  247.    Multi-Media Conferencing
  248.  
  249.       Such conferencing requires the exchange of large amounts of
  250.       information in short periods of time.  Hence the requirement for
  251.       high bandwidth at low delay.  We estimate that the bandwidth would
  252.       range from 1.5 to 100 Mbit/s, with an end-to-end delay of no more
  253.       than a few hundred msec.
  254.  
  255.    Computer-Generated Real-time Graphics
  256.  
  257.       Visualizing computer results in the modern world of supercomputers
  258.       requires large amounts of real time graphics.  This in turn will
  259.       require about 1.5 Mbit/s of bandwidth and no more than several
  260.       hundred msec.  delay.
  261.  
  262.    High-Speed Transaction Processing
  263.  
  264.       One of the most important reasons for having an ultra-high-speed
  265.       network is to take advantage of supercomputing capability.  There
  266.       are several scenarios in which this capability could be utilized.
  267.       For example, there could be instances where a non-supercomputer
  268.       may require a supercomputer to perform some processing and provide
  269.       some intermediate results that will be used to perform still
  270.       further processing, or the exchange may be between several
  271.       supercomputers operating in tandem and periodically exchanging
  272.       results, such as in a battle management, war gaming, or process
  273.       control applications.  In such cases, extremely short response
  274.       times are necessary to accomplish as many as hundreds of
  275.       interactions in real time.  This requires very high bandwidth, on
  276.       the order of 100 Mbit/s, and minimum delay, on the order of
  277.       hundreds of msec.
  278.  
  279.  
  280.  
  281.  
  282. Gigabit Working Group                                           [Page 5]
  283.  
  284. RFC 1077                                                   November 1988
  285.  
  286.  
  287.    Wide-Area Distributed Data/Knowledge Base Management Systems
  288.  
  289.       Computer-stored data, information, and knowledge is distributed
  290.       around the country for a variety of reasons.  The ability to
  291.       perform complex queries, updates, and report generation as though
  292.       many large databases are one system would be extremely powerful,
  293.       yet requires low-delay, high-bandwidth communication for
  294.       interactive use.  The Corporation for National Research
  295.       Initiatives (NRI) has promoted the notion of a National Knowledge
  296.       base with these characteristics.  In particular, an attractive
  297.       approach is to cache views at the user sites, or close by to allow
  298.       efficient repeated queries and multi-relation processing for
  299.       relations on different nodes.  However, with caching, a processing
  300.       activity may incur a miss in the midst of a query or update,
  301.       causing it to be delayed by the time required to retrieve the
  302.       missing relation or portion of relation.  To minimize the overhead
  303.       for cache directories, both at the server and client sites, the
  304.       unit of caching should be large---say a megabyte or more.  In
  305.       addition, to maintain consistency at the caching client sites,
  306.       server sites need to multicast invalidations and/or updates.
  307.       Communication requirements are further increased by replication of
  308.       the data.  The critical parameter is latency for cache misses and
  309.       consistency operations.  Taking the distance between sites to be
  310.       on average 1/4 the diameter of the country, a one Gbit/s data rate
  311.       is required to reduce the transmission time to be roughly the same
  312.       as the propagation delay, namely around 8 milliseconds for this
  313.       size of unit.  Note that this application is supporting far more
  314.       sophisticated queries and updates than normally associated with
  315.       transaction processing, thus requiring larger amount of data to be
  316.       transferred.
  317.  
  318.  
  319.    2.2.  Types of Traffic and Communications Modes
  320.  
  321.  
  322.    Different types of traffic may impose different constraints in terms
  323.    of throughput, delay, delay dispersion, reliability and sequenced
  324.    delivery.  Table 1 summarizes some of the main characteristics of
  325.    several different types of traffic.
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Gigabit Working Group                                           [Page 6]
  339.  
  340. RFC 1077                                                   November 1988
  341.  
  342.  
  343.                 Table 1: Communication Traffic Requirements
  344.  
  345.    +------------------------+-------------+-------------+-------------+
  346.    |                        |             |             | Error-free  |
  347.    | Traffic                | Delay       | Throughput  | Sequenced   |
  348.    | Type                   | Requirement | Requirement | Delivery    |
  349.    +------------------------+-------------+-------------+-------------+
  350.    | Interactive Simulation | Low         |Moderate-High| No          |
  351.    +------------------------+-------------+-------------+-------------+
  352.    | Network Monitoring     | Moderate    | Low         | No          |
  353.    +------------------------+-------------+-------------+-------------+
  354.    | Virtual Terminal       | Low         | Low         | Yes         |
  355.    +------------------------+-------------+-------------+-------------+
  356.    | Bulk Transfer          | High        | High        | Yes         |
  357.    +------------------------+-------------+-------------+-------------+
  358.    | Message                | Moderate    | Moderate    | Yes         |
  359.    +------------------------+-------------+-------------+-------------+
  360.    | Voice                  |Low, constant| Moderate    | No          |
  361.    +------------------------+-------------+-------------+-------------+
  362.    | Video                  |Low, constant| High        | No          |
  363.    +------------------------+-------------+-------------+-------------+
  364.    | Facsimile              | Moderate    | High        | No          |
  365.    +------------------------+-------------+-------------+-------------+
  366.    | Image Transfer         | Variable    | High        | No          |
  367.    +------------------------+-------------+-------------+-------------+
  368.    | Distributed Computing  | Low         | Variable    | Yes         |
  369.    +------------------------+-------------+-------------+-------------+
  370.    | Network Control        | Moderate    | Low         | Yes         |
  371.    +------------------------+-------------+-------------+-------------+
  372.  
  373.    The topology among users can be of three types: point-to-point (one-
  374.    to-one connectivity), multicast (one sender and multiple receivers),
  375.    and conferencing (multiple senders and multiple receivers).  There
  376.    are three types of transfers that can take place among users.  They
  377.    are connection-oriented network service, connectionless network
  378.    service, and stream or synchronous traffic.  Connection and
  379.    connectionless services are asynchronous.  A connection-oriented
  380.    service assumes and provides for relationships among the multiple
  381.    packets sent over the connection (e.g., to a common destination)
  382.    while connectionless service assumes each packet is a complete and
  383.    separate entity unto itself.  For stream or synchronous service a
  384.    reservation scheme is used to set up and guarantee a constant and
  385.    steady amount of bandwidth between any two subscribers.
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Gigabit Working Group                                           [Page 7]
  395.  
  396. RFC 1077                                                   November 1988
  397.  
  398.  
  399.    2.3.  Network Backbone
  400.  
  401.  
  402.    The GB needs to be of high bandwidth to support a large population of
  403.    users, and additionally to provide high-speed connectivity among
  404.    certain subscribers who may need such capability (e.g., between two
  405.    supercomputers).  These users may access the GN from local area
  406.    networks (LANs) directly connected to the backbone or via high-speed
  407.    intermediate regional networks.  The backbone must also minimize
  408.    end-to-end delay to support highly interactive high-speed
  409.    (supercomputer) activities.
  410.  
  411.    It is important that the LANs that will be connected to the GN be
  412.    permitted data rates independent of the data rates of the GB.  LAN
  413.    speeds should be allowed to change without affecting the GB, and the
  414.    GB speeds should be allowed to change without affecting the LANs.  In
  415.    this way, development of the technology for LANs and the GB can
  416.    proceed independently.
  417.  
  418.    Access rate requirements to the GB and the GN will vary depending on
  419.    user requirements and local environments.  The users may require
  420.    access rates ranging from multi-kbit/s in the case of terminals or
  421.    personal computers connected by modems up to multi-Mbit/s and beyond
  422.    for powerful workstations up to the Gbit/s range for high-speed
  423.    computing and data resources.
  424.  
  425.  
  426.    2.4.  Directory Services
  427.  
  428.  
  429.    Directory services similar to those found in CCITT X.500/ISO DIS 9594
  430.    need to be provided.  These include mapping user names to electronic
  431.    mail addresses, distribution lists, support for authorization
  432.    checking, access control, and public key encryption schemes,
  433.    multimedia mail capabilities, and the ability to keep track of mobile
  434.    users (those who move from place to place and host computer to host
  435.    computer).  The directory services may also list facilities available
  436.    to users via the network.  Some examples are databases,
  437.    supercomputing or other special-purpose applications, and on-line
  438.    help or telephone hotlines.
  439.  
  440.    The services provided by X.500 may require some extension for GN.
  441.    For example, there is no provision for multilevel security, and the
  442.    approach taken to authentication must be studied to ensure that it
  443.    meets the requirements of GN and its user community.
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Gigabit Working Group                                           [Page 8]
  451.  
  452. RFC 1077                                                   November 1988
  453.  
  454.  
  455.    2.5.  Network Management and Routing
  456.  
  457.  
  458.    The objective of network management is to ensure that the network
  459.    functions smoothly and efficiently, and consists of the following:
  460.    accounting, security, performance monitoring, fault isolation and
  461.    configuration control.
  462.  
  463.    Accounting ensures that users are properly billed for the services
  464.    that the network provides.  Accounting enforces a tariff; a tariff
  465.    expresses a usage policy.  The network need only keep track of those
  466.    items addressed by the tariff, such as allocated bandwidth, number of
  467.    packets sent, number of ports used, etc.  Another type of accounting
  468.    may need to be supported by the network to support resource sharing,
  469.    namely accounting analogous to telephone "900" numbers.  This
  470.    accounting performed by the network on behalf of resource providers
  471.    and consumers is a pragmatic solution to the problem of getting the
  472.    users and consumers into a financial relationship with each other
  473.    which has stymied previous attempts to achieve widespread use of
  474.    specialized resources.
  475.  
  476.    Performance monitoring is needed so that the managers can tell how
  477.    the network is performing and take the necessary actions to keep its
  478.    performance at a level that will provide users with satisfactory
  479.    service.  Fault isolation using technical control mechanisms is
  480.    needed for network maintenance.  Configuration management allows the
  481.    network to function efficiently.
  482.  
  483.    Several new types of routing will be required by GN.  In addition to
  484.    true type-of-service, needed to support diverse distributed
  485.    applications, real-time applications, interactive applications, and
  486.    bulk data transfer, there will be need for traffic controls to
  487.    enforce various routing policies.  For example, policy may dictate
  488.    that traffic from certain users, applications,  or hosts may not be
  489.    permitted to traverse certain segments of the network.
  490.    Alternatively, traffic controls may be used to promote fairness; that
  491.    is, to make sure that busy link or network segment isn't dominated by
  492.    a particular source or destination.  The ability of applications to
  493.    reserve network bandwidth in advance of its use, and the use of
  494.    strategies such as soft connections, will also require development of
  495.    new routing algorithms.
  496.  
  497.  
  498.    2.6.  Network Security Requirements
  499.  
  500.  
  501.    Security is a critical factor within the GN and one of those features
  502.    that are difficult to provide.  It is envisioned that both
  503.  
  504.  
  505.  
  506. Gigabit Working Group                                           [Page 9]
  507.  
  508. RFC 1077                                                   November 1988
  509.  
  510.  
  511.    unclassified and classified traffic will utilize the GN, so
  512.    protection mechanisms must be an integral part of the network access
  513.    strategy.  Features such as authentication, integrity,
  514.    confidentiality, access control, and nonrepudiation are essential to
  515.    provide trusted and secure communication services for network users.
  516.  
  517.    A subscriber must have assurance that the person or system he is
  518.    exchanging information with is indeed who he says he is.
  519.    Authentication provides this assurance by verifying that the claimed
  520.    source of a query request, control command, response, etc., is the
  521.    actual source.  Integrity assures that the subscriber's information
  522.    (such as requests, commands, data, responses, etc.) is not changed,
  523.    intentionally or unintentionally, while in transit or by replays of
  524.    earlier traffic.  Unauthorized users (e.g., intruders or network
  525.    viruses) would be denied use of GN assets through access control
  526.    mechanisms which verify that the authenticated source is authorized
  527.    to receive the requested information or to initiate the specified
  528.    command.  In addition, nonrepudiation services can be offered to
  529.    assure a third party that the transmitted information has not been
  530.    altered.  And finally, confidentiality will ensure that the contents
  531.    of a message are not divulged to unauthorized individuals.
  532.    Subscribers can decide, based upon their own security needs and
  533.    particular activities, which of these services are necessary at a
  534.    given time.
  535.  
  536.  
  537.    3.  Critical Research Issues
  538.  
  539.  
  540.    In the section above, we discussed the goals of a research program in
  541.    gigabit networking; namely to provide the technology base for a
  542.    network that will allow gigabit service to be provided in an
  543.    effective way.  In this section, we discuss those issues which we
  544.    feel are critical to address in a research program to achieve such
  545.    goals.
  546.  
  547.  
  548.    3.1.  General Architectural Issues
  549.  
  550.  
  551.    In the last generation of networks, it was assumed that bandwidth was
  552.    the scarce resource and the design of the switch was dictated by the
  553.    need to manage and allocate the bandwidth effectively.  The most
  554.    basic change in the next generation network is that the speeds of the
  555.    trunks are rising faster than the speeds of the switching elements.
  556.  
  557.    This change in the balance of speeds has manifested itself in several
  558.    ways.  In most current designs for local area networks, where
  559.  
  560.  
  561.  
  562. Gigabit Working Group                                          [Page 10]
  563.  
  564. RFC 1077                                                   November 1988
  565.  
  566.  
  567.    bandwidth is not expensive, the design decision was to trade off
  568.    effective use of the bandwidth for a simplified switching technique.
  569.    In particular, networks such as Ethernet use broadcast as the normal
  570.    distribution method, which essentially eliminates the need for a
  571.    switching element.
  572.  
  573.    As we look at still higher speed networks, and in particular networks
  574.    in which the bandwidth is still the expensive component, we must
  575.    design new options for switching which will permit effective use of
  576.    bandwidth without the switch itself becoming the bottleneck.
  577.  
  578.    The central thrust of new research must thus be to explore new
  579.    network architectures that are consistent with these very different
  580.    speed assumptions.
  581.  
  582.    The development of computer communications has been tremendously
  583.    distorted by the characteristics of wide-area networking: normally
  584.    high cost, low speed, high error rate, large delay.  The time is ripe
  585.    for a revolution in thinking, technology, and approaches, analogous
  586.    to the revolution caused by VCR technology over 8 and 16 mm. film
  587.    technology.
  588.  
  589.    Fiber optics is clearly the enabling technology for high-speed
  590.    transmission, in fact, so much so that there is an expectation that
  591.    the switching elements will now hold down the data rates.  Both
  592.    conventional circuit switching and packet switching have significant
  593.    problems at higher data rates.  For instance, circuit switching
  594.    requires increasing delays for FTDM synchronization to handle skew.
  595.    In the case of packet switching, traditional approaches require too
  596.    much processing per packet to handle the tremendous data flow.  The
  597.    problem for both switching regimes is the "intelligence" in the
  598.    switches, which in turn requires electronics technology.
  599.  
  600.    Besides intelligence, another problem for wide-area networks is
  601.    storage, both because it ties us to electronics (for the foreseeable
  602.    future) and because it produces instabilities in a large-scale
  603.    system.  (See, for instance, the work by Van Jacobson on self-
  604.    organizing phenomena for self-destruction in the Internet.)
  605.    Techniques are required to eliminate dependence on storage, such as
  606.    cut-through routing.
  607.  
  608.    Overall, high-speed WANs are the greatest agents of change, the
  609.    greatest catalyst both commercially and militarily, and the area ripe
  610.    for revolution.  Judging by the attributes of current high-speed
  611.    network research prototypes, WANs of the future will be photonic,
  612.    multi-gigabit networks with enormous throughput, low delay, and low
  613.    error rate.
  614.  
  615.  
  616.  
  617.  
  618. Gigabit Working Group                                          [Page 11]
  619.  
  620. RFC 1077                                                   November 1988
  621.  
  622.  
  623.    A zero-based budgeting approach is required to develop the new high-
  624.    speed internetwork architecture.  That is, the time is ripe to
  625.    significantly rethink the Internet, building on experience with this
  626.    system.  Issues of concern are manageability, understanding
  627.    evolvability and support for the new communication requirements,
  628.    including remote procedure call, real-time, security and fault-
  629.    tolerance.
  630.  
  631.    The GN must be able to deal with two sources of high-bandwidth
  632.    requirements.  There will be some end devices (computers) connected
  633.    more or less directly to the GN because of their individual
  634.    requirements for high bandwidth (e.g., supercomputers needing to
  635.    drive remote high-bandwidth graphics devices).  In addition, the
  636.    aggregate traffic due to large numbers of moderate rate users
  637.    (estimates are roughly up to a million potential users needing up to
  638.    1 Mbit/s at any given time) results in a high-bandwidth requirement
  639.    in total on the GN.  The statistics of such traffic are different and
  640.    there are different possible technical approaches for dealing with
  641.    them.  Thus, an architectural approach for dealing with both must be
  642.    developed.
  643.  
  644.    Overall, the next-generation architecture has to be, first and
  645.    foremost, a management architecture.  The directions in link speeds,
  646.    processor speeds and memory solve the performance problems for many
  647.    communication situations so well that manageability becomes the
  648.    predominant concern.  (In fact, fast communication makes large
  649.    systems more prone to performance, reliability, and security
  650.    problems.)  In many ways, the management system of the internetwork
  651.    is the ultimate distributed system.  The solution to this tough
  652.    problem may well require the best talents from the communications,
  653.    operating systems and distributed systems communities, perhaps even
  654.    drawing on database and parallelism research.
  655.  
  656.  
  657.    3.1.1.  High-Speed Internet using High-Speed Networks
  658.  
  659.  
  660.    The GN will need to take advantage of a multitude of different and
  661.    heterogeneous networks, all of high speed.  In addition to networks
  662.    based on the technology of the GB, there will be high-speed LANs.  A
  663.    key issue in the development of the GN will be the development of a
  664.    strategy for interconnecting such networks to provide gigabit service
  665.    on an end to end basis.  This will involve techniques for switching,
  666.    interfacing, and management (as discussed in the sections below)
  667.    coupled with an architecture that allows the GN to take full
  668.    advantage of the performance of the various high-speed networks.
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Gigabit Working Group                                          [Page 12]
  675.  
  676. RFC 1077                                                   November 1988
  677.  
  678.  
  679.    3.1.2.  Network Organization
  680.  
  681.  
  682.    The GN will need an architecture that supports the need to manage the
  683.    system as well as obtain high performance.  We note that almost all
  684.    human-engineered systems are hierarchically structured from the
  685.    standpoint of control, monitoring, and information flow.  A
  686.    hierarchical design may be the key to manageability in the next-
  687.    generation architecture.
  688.  
  689.    One approach is to use a general three-level structure, corresponding
  690.    to interadministrational, intraadministrational, and cluster
  691.    networks.  The first level interconnects communication facilities of
  692.    truly separate administrations where there is significant separation
  693.    of security, accounting, and goals.  The second level interconnects
  694.    subadministrations which exist for management convenience in large
  695.    organizations.  For example, a research group within a university may
  696.    function as a subadministration.  The cluster level consists of
  697.    networks configured to provides maximal performance among hosts which
  698.    are in frequent communication, such as a set of diskless workstations
  699.    and their common file server.  These hosts are typically, but not
  700.    necessarily, geographically collocated.  For example, two remote
  701.    networks may be tightly coupled by a fiber optic link that bridges
  702.    between the two physical networks, making them function as one.
  703.  
  704.    Research along these lines should study the interorganizational
  705.    characteristics of communications, such as those being investigated
  706.    by the IAB Task Force on Autonomous Networks.  Based on current
  707.    results, we expect that such work would clearly demonstrate that
  708.    considerable communication takes place between particular
  709.    subadministrations in different administrations; communication
  710.    patterns are not strictly hierarchical.  For example, there might be
  711.    intense direct communication between the experimental physics
  712.    departments of two independent universities, or between the computer
  713.    support group of one company and the operating system development
  714.    group of another.  In addition, (sub)administrations may well also
  715.    require divisions into public information and private information.
  716.  
  717.  
  718.    3.1.3.  Fault-Tolerant System
  719.  
  720.  
  721.    Although the GN will be developed as part of an experimental research
  722.    program, it will also serve as part of the infrastructure for
  723.    researchers who are experimenting with applications which will use
  724.    such a network.  The GN must have reasonably high availability to
  725.    support these research activities.  In addition to facilitate the
  726.    transfer of this technology to future operational military and
  727.  
  728.  
  729.  
  730. Gigabit Working Group                                          [Page 13]
  731.  
  732. RFC 1077                                                   November 1988
  733.  
  734.  
  735.    commercial users, it will need to be designed to become highly
  736.    reliable.  This can be accomplished through diversity of transmission
  737.    paths, the development of fault-tolerant switches, use of a
  738.    distributed control structure with self-correcting algorithms, and
  739.    the protection of network control traffic.  The architecture of a GN
  740.    should support and allow for all of these things.
  741.  
  742.  
  743.    3.1.4.  Functional Division of Control Between Network Elements
  744.  
  745.  
  746.    Current protocol architectures use the layered model of functional
  747.    decomposition first developed in the early work on ARPANET protocols.
  748.    The concept of layering has been a powerful concept which has allowed
  749.    dramatic variation in network technologies without requiring the
  750.    complete reimplementation of applications.  The concept of layering
  751.    has had a first-order impact on the development of international
  752.    standards for data communication---witness the ISO "Reference Model
  753.    for Open Systems Interconnection."
  754.  
  755.    Unfortunately, however, the powerful concept of layering has been
  756.    paired, both in the DoD Internet work and the ISO work, with an
  757.    extremely weak concept of the interface between layers.  The
  758.    interface designs are all organized around the idea of commands and
  759.    responses plus an error indicator.  For example, the TCP service
  760.    interface provides the user with commands to set up or close a TCP
  761.    connection and commands to send and receive datagrams.  The user may
  762.    well "know" whether they are using a file transfer service or a
  763.    character-at-a- time virtual terminal, but can't tell the TCP.  The
  764.    underlying network may "know" that failures have reduced the path to
  765.    the user's destination to a single 9.6 kbit/s link, but it also can't
  766.    tell the TCP implementation.
  767.  
  768.    All of the information that an analyst would consider crucial in
  769.    diagnosing system performance is carefully hidden from adjacent
  770.    layers.  One "solution" often discussed (but rarely implemented) is
  771.    to condense all of this information into a few bits of "Type of
  772.    Service" or "Quality of Service" request flowing in one direction
  773.    only---from application to network.  It seems likely that this
  774.    approach cannot succeed, both because it applies too much compression
  775.    to the knowledge available and because it does not provide two-way
  776.    flow.
  777.  
  778.    We believe it to be likely that the next-generation network will
  779.    require a much richer interface between every pair of adjacent layers
  780.    if adequate performance is to be achieved.  Research is needed into
  781.    the conceptual mechanisms, both indicators and controls, that can be
  782.    implemented at these interfaces and that, when used, will result in
  783.  
  784.  
  785.  
  786. Gigabit Working Group                                          [Page 14]
  787.  
  788. RFC 1077                                                   November 1988
  789.  
  790.  
  791.    better performance.  If real differences in performance can be
  792.    observed, then the implementors of every layer will have a strong
  793.    incentive to make use of the mechanisms.
  794.  
  795.    We can observe the first glimmers of this sort of coordination
  796.    between layers in current work.  For example, in the ISO work there
  797.    are 5 classes of transport protocol which are supposed to provide a
  798.    range of possible matches between application needs and network
  799.    capabilities.  Unfortunately, it is the case today that the class of
  800.    transport protocol is chosen statically, by the implementer, rather
  801.    than dynamically.  The DARPA Wideband net offers a choice of stream
  802.    or datagram service, but typically a given host uses all one or all
  803.    the other---again, a static rather than a dynamic choice.  The
  804.    research that we believe is needed, therefore, is not how to provide
  805.    alternatives, but how to provide them and choose among them on a
  806.    dynamic, real-time basis.
  807.  
  808.  
  809.    3.1.5.  Different Switch Technologies
  810.  
  811.  
  812.    One approach to high-performance networking is to design a technology
  813.    that is expected to work as a stand-alone demonstration, without
  814.    addressing the need for interconnection to other networks.  Such an
  815.    experiment may be very valuable for rapid exploration of the design
  816.    space.  However, our experience with the Internet project suggests
  817.    that a primary research goal should be the development of a network
  818.    architecture that permits the interconnection of a number of
  819.    different switching technologies.
  820.  
  821.    The Internet project was successful to a large extent because it
  822.    could incorporate a number of new and preexisting network
  823.    technologies: various local area networks, store and forward
  824.    switching networks, broadcast satellite nets, packet radio networks,
  825.    and so on.  In this way, it decoupled the use of the protocols from a
  826.    particular technology base.  In fact, the technology base evolved
  827.    rapidly, but the Internet protocols themselves provided a stability
  828.    that led to their success.
  829.  
  830.    The next-generation architecture must similarly deal with a diverse
  831.    and evolving technology base.  We see "fast-packet" switching now
  832.    being developed (for example in B-ISDN); we see photonic switching
  833.    and wavelength division multiplexing as more advanced technologies.
  834.    We must divorce our architecture from dependence on any one of these.
  835.  
  836.    At the host interface, we must divorce the multiplexing of the medium
  837.    from the form of data that the host sees.  Today the packet is used
  838.    both as multiplexing and interface element.  In the future, the host
  839.  
  840.  
  841.  
  842. Gigabit Working Group                                          [Page 15]
  843.  
  844. RFC 1077                                                   November 1988
  845.  
  846.  
  847.    may see the network as a message-passing system, or as memory.  At
  848.    the same time, the network may use classic packets, wavelength
  849.    division, or space division switching.
  850.  
  851.    A number of basic functions must be rethought to provide an
  852.    architecture that is not dependent on the underlying switching model.
  853.    For example, our transport protocols assume that data will be lost in
  854.    units of a packet.  If part of a packet is lost, we discard the whole
  855.    thing.  And if several packets are systematically lost in sequence,
  856.    we may not recover effectively.  There must be a host-level unit of
  857.    error recovery that is independent of the network.  This sort of
  858.    abstraction must be applied to all the aspects of service
  859.    specification: error recovery, flow control, addressing, and so on.
  860.  
  861.  
  862.    3.1.6.  Network Operations, Monitoring, and Control
  863.  
  864.  
  865.    There is a hierarchy of progressively more effective and
  866.    sophisticated techniques for network management that applies
  867.    regardless of network bandwidth and application considerations:
  868.  
  869.       1.  Reactive problem management
  870.  
  871.       2.  Reactive resource management
  872.  
  873.       3.  Proactive problem management
  874.  
  875.       4.  Proactive resource management.
  876.  
  877.    Today's network management strategies are primarily reactive rather
  878.    than proactive:  Problem management is initiated in response to user
  879.    complaints about service outages; resource allocation decisions are
  880.    made when users complain about deterioration of quality of service.
  881.    Today's network management systems are stuck at step 1 or perhaps
  882.    step 2 of the hierarchy.
  883.  
  884.    Future network management systems will provide proactive problem
  885.    management---problem diagnosis and restoral of service before users
  886.    become aware that there was a problem; and proactive resource
  887.    management---dynamic allocation of network bandwidth and switching
  888.    resources to ensure that an acceptable level of service is
  889.    continuously maintained.
  890.  
  891.    The GN management system should be expected to provide proactive
  892.    problem and resource management capabilities.  It will have to do so
  893.    while contending with three important changes in the managed network
  894.    environment:
  895.  
  896.  
  897.  
  898. Gigabit Working Group                                          [Page 16]
  899.  
  900. RFC 1077                                                   November 1988
  901.  
  902.  
  903.       1.  More complicated devices under management
  904.  
  905.       2.  More diverse types of devices
  906.  
  907.       3.  More variety of application protocols.
  908.  
  909.    Performance under these conditions will require that we seriously
  910.    re-think how a network management system handles the expected high
  911.    volumes of raw management-related data.  It will become especially
  912.    important for the system to provide thresholding, filtering, and
  913.    alerting mechanisms that can save the human operator from drowning in
  914.    data, while still permitting access to details when diagnostic or
  915.    fault isolation modes are invoked.
  916.  
  917.    The presence of expert assistant capabilities for early fault
  918.    detection, diagnosis, and problem resolution will be mandatory.
  919.    These capabilities are highly desirable today, but they will be
  920.    essential to contend with the complexity and diversity of devices and
  921.    applications in the Gigabit Network.
  922.  
  923.    In addition to its role in dealing with complexity, automation
  924.    provides the only hope of controlling and reducing the high costs of
  925.    daily management and operation of a GN.
  926.  
  927.    Proactive resource management in GNs must be better understood and
  928.    practiced, initially as an effort requiring human intervention and
  929.    direction.  Once this is achieved, it too must become automated to a
  930.    high degree in the GN.
  931.  
  932.  
  933.    3.1.7.  Naming and Addressing Strategies
  934.  
  935.  
  936.    Current networks, both voice (telephone) and data, use addressing
  937.    structures which closely tie the address to the physical location on
  938.    the network.  That is, the address identifies a physical access
  939.    point, rather than the higher-level entity (computer, process, human)
  940.    attached to that access point.  In future networks, this physical
  941.    aspect of addressing must be removed.
  942.  
  943.    Consider, for example, finding the desired party in the telephone
  944.    network of today.  For a person not at his listed number, finding the
  945.    number of the correct telephone may require preliminary calls, in
  946.    which advice is given to the person placing the call.  This works
  947.    well when a human is placing the call, since humans are well equipped
  948.    to cope with arbitrary conversations.  But if a computer is placing
  949.    the call, the process of obtaining the correct address will have to
  950.    be incorporated in the architecture as a core service of the network.
  951.  
  952.  
  953.  
  954. Gigabit Working Group                                          [Page 17]
  955.  
  956. RFC 1077                                                   November 1988
  957.  
  958.  
  959.    Since it is reasonable to expect mobile hosts, hosts that are
  960.    connected to multiple networks, and replicated hosts, the issue of
  961.    mapping to the physical address must be properly resolved.
  962.  
  963.    To permit the network to maintain the dynamic mapping to current
  964.    physical address, it is necessary that high-level entities have a
  965.    name (or logical address) that identifies them independently of
  966.    location.  The name is maintained by the network, and mapped to the
  967.    current physical location as a core network service.  For example,
  968.    mobile hosts, hosts that are connected to multiple networks, and
  969.    replicated hosts would have static names whose mapping to physical
  970.    addresses (many-to-one, in some cases) would change with time.
  971.  
  972.    Hosts are not the only entities whose physical location varies.
  973.    Users' electronic mail addresses change.  Within distributed systems,
  974.    processes and files migrate from host to host.  In a computing
  975.    environment where robustness and survivability are important, entire
  976.    applications may move about, or they may be redundant.
  977.  
  978.    The needed function must be considered in the context of the mobility
  979.    and address resolution rates if all addresses in a global data
  980.    network were of this sort.  The distributed network directory
  981.    discussed elsewhere in this report should be designed to provide the
  982.    necessary flexibility, and responsiveness.  The nature and
  983.    administration of names must also be considered.
  984.  
  985.    Names that are arbitrary or unwieldy would be barely better than the
  986.    addresses used now.  The name space should be designed so that it can
  987.    easily be partitioned among the agencies that will assign names.  The
  988.    structure of names should facilitate, rather than hinder, the mapping
  989.    function.  For example, it would be hard to optimize the mapping
  990.    function if names were flat and unstructured.
  991.  
  992.  
  993.    3.2.  High-Speed Switching
  994.  
  995.  
  996.    The term "high-speed switching" refers to changing the switching at a
  997.    high rate, rather than switching high-speed links, because the latter
  998.    is not difficult at low speeds.  (Consider, for example, manual
  999.    switching of fiber connections).  The switching regime chosen for the
  1000.    network determines various aspects of its performance, its charging
  1001.    policies, and even its effective capabilities.  As an example of the
  1002.    latter, it is difficult to expect a circuit-switched network to
  1003.    provide strong multicast support.
  1004.  
  1005.    A major area of debate lies in the choice between packet switching
  1006.    and circuit switching.  This is a key research issue for the GN,
  1007.  
  1008.  
  1009.  
  1010. Gigabit Working Group                                          [Page 18]
  1011.  
  1012. RFC 1077                                                   November 1988
  1013.  
  1014.  
  1015.    considering also the possibility of there being combinations of the
  1016.    two approaches that are feasible.
  1017.  
  1018.  
  1019.    3.2.1.  Unit of Management vs. Multiplexing
  1020.  
  1021.  
  1022.    With very high data rates, either the unit of management and
  1023.    switching must be larger or the speed of the processor elements for
  1024.    management and switching must be faster.  For example, at a gigabit,
  1025.    a 576 byte packet takes roughly 5 microseconds to be received so a
  1026.    packet switch must act extremely fast to avoid being the dominant
  1027.    delay in packet times.  Moreover, the storage time for the packet in
  1028.    a conventional store and forward implementation also becomes a
  1029.    significant component of the delay.  Thus, for packet switching to
  1030.    remain attractive in this environment, it appears necessary to
  1031.    increase the size of packets (or switch on packet groups), do so-
  1032.    called virtual cut-through and use high-speed routing techniques,
  1033.    such as high-speed route caches and source routing.
  1034.  
  1035.    Alternatively, for circuit switching to be attractive, it must
  1036.    provide very fast circuit setup and tear-down to support the bursty
  1037.    nature of most computer communication.  This problem is rendered
  1038.    difficult (and perhaps impossible for certain traffic loads) because
  1039.    the delay across the country is so large relative to the data rate.
  1040.    That is, even with techniques such as so-called fast select,
  1041.    bandwidth is reserved by the circuit along the path for almost twice
  1042.    the propagation time before being used.
  1043.  
  1044.    With gigabit circuit switching, because it is not feasible to
  1045.    physically switch channels, the low-level switching is likely doing
  1046.    FTDM on micro-packets, as is currently done in telephony.  Performing
  1047.    FTDM at gigabit data rates is a challenging research problem if the
  1048.    skew introduced by wide-area communication is to be handled with
  1049.    reasonable overhead for spacing of this micro-packets.  Given the
  1050.    lead and resources of the telephone companies, this area of
  1051.    investigation should, if pursued, be pursued cooperatively.
  1052.  
  1053.  
  1054.    3.2.2.  Bandwidth Reservation Algorithms
  1055.  
  1056.  
  1057.    Some applications, such as real-time video, require sustained high
  1058.    data rate streams over a significant period of time, such as minutes
  1059.    if not hours.  Intuitively, it is appealing for such applications to
  1060.    pre-allocate the bandwidth they require to minimize the switching
  1061.    load on the network and guarantee that the required bandwidth is
  1062.    available.  Research is required to determine the merits of bandwidth
  1063.  
  1064.  
  1065.  
  1066. Gigabit Working Group                                          [Page 19]
  1067.  
  1068. RFC 1077                                                   November 1988
  1069.  
  1070.  
  1071.    reservation, particular in conjunction with the different switching
  1072.    technologies.  There is some concern to raise that bandwidth
  1073.    reservation may require excessive intelligence in the network,
  1074.    reducing the performance and reliability of the network.  In
  1075.    addition, bandwidth reservation opens a new option for denial of
  1076.    service by an intruder or malicious user.  Thus, investigations in
  1077.    this area need to proceed in concert with work on switching
  1078.    technologies and capabilities and security and reliability
  1079.    requirements.
  1080.  
  1081.  
  1082.    3.2.3.  Multicast Capabilities
  1083.  
  1084.  
  1085.    It is now widely accepted that multicast should be provided as a
  1086.    user-level service, as described in RFC 1054 for IP, for example.
  1087.    However, further research is required to determine the best way to
  1088.    support this facility at the network layer and lower.  It is fairly
  1089.    clear that the GN will be built from point-to-point fiber links that
  1090.    do not provide multicast/broadcast for free.  At the most
  1091.    conservative extreme, one could provide no support and require that
  1092.    each host or gateway simulate multicast by sending multiple,
  1093.    individually addressed packets.  However, there are significant
  1094.    advantages to providing very low level multicast support (besides the
  1095.    obvious performance advantages).  For example, multicast routing in a
  1096.    flooding form provides the most fault-tolerant, lowest-delay form of
  1097.    delivery which, if reserved for very high priority messages, provides
  1098.    a good emergency facility for high-stress network applications.
  1099.    Multicast may also be useful as an approach to defeat traffic
  1100.    analysis.
  1101.  
  1102.    Another key issue arises with the distinction between so-called open
  1103.    group multicast and closed group multicast.  In the former, any host
  1104.    can multicast to the group, whereas in the latter, only members of
  1105.    the group can multicast to it.  The latter is easier to support and
  1106.    adequate for conferencing, for example.  However, for more client-
  1107.    server structured applications, such as using file/database server,
  1108.    computation servers, etc. as groups, open multicast is required.
  1109.    Research is needed to address both forms of multicast.  In addition,
  1110.    security issues arise in controlling the membership of multicast
  1111.    groups.  This issue should be addressed in concert with work on
  1112.    secure forms of routing in general.
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121.  
  1122. Gigabit Working Group                                          [Page 20]
  1123.  
  1124. RFC 1077                                                   November 1988
  1125.  
  1126.  
  1127.    3.2.4.  Gateway Technologies
  1128.  
  1129.  
  1130.    With the wide-area interconnection of local networks by the GN,
  1131.    gateways are expected to become a significant performance bottleneck
  1132.    unless significant advances are made in gateway performance.  In
  1133.    addition, many network management concerns suggest putting more
  1134.    functionality (such as access control) in the gateways, further
  1135.    increasing their load and the need for greater capacity.  This would
  1136.    then raise the issue of the trade-off between general-purpose
  1137.    hardware and special-purpose hardware.
  1138.  
  1139.    On the general-purpose side, it may be feasible to use a general-
  1140.    purpose multiprocessor based on high-end microprocessors (perhaps as
  1141.    exotic as the GaAs MIPS) in conjunction with a high-speed block
  1142.    transfer bus, as proposed as part of the FutureBus standard (which is
  1143.    extendible to higher speeds than currently commercially planned) and
  1144.    intelligent high-speed network adaptors.  This would also allow the
  1145.    direct use of hardware, operating systems, and software tools
  1146.    developed as part of other DARPA programs, such as Strategic
  1147.    Computing.  It also appears to make this gateway software more
  1148.    portable to commercial machines as they become available in this
  1149.    performance range.
  1150.  
  1151.    The specialized hardware approach is based on the assumption that
  1152.    general-purpose hardware, particularly the interconnection bus,
  1153.    cannot be fast enough to support the level of performance required.
  1154.    The expected emphasis is on various interconnection network
  1155.    techniques.  These approaches appear to require greater expense, less
  1156.    commercial availability and more specialized software.  They need to
  1157.    be critically evaluated with respect to the general-purpose gateway
  1158.    hardware approach, especially if the latter is using multiple buses
  1159.    for fault-tolerance as well as capacity extension (in the absence of
  1160.    failure).
  1161.  
  1162.    The same general-purpose vs. special-purpose contention is an issue
  1163.    with operating system software.  Conventionally, gateways run
  1164.    specialized run-time executives that are designed specifically for
  1165.    the gateway and gateway functions.  However, the growing
  1166.    sophistication of the gateway makes this approach less feasible.  It
  1167.    appears important to investigate the feasibility of using a standard
  1168.    operating system foundation on the gateways that is known to provide
  1169.    the required security and reliability properties (as well as real-
  1170.    time performance properties).
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.  
  1177.  
  1178. Gigabit Working Group                                          [Page 21]
  1179.  
  1180. RFC 1077                                                   November 1988
  1181.  
  1182.  
  1183.    3.2.5.  VLSI and Optronics Implementations
  1184.  
  1185.  
  1186.    It appears fairly clear that gigabit communication will use fiber
  1187.    optics for at least the near future.  Without major advances in
  1188.    optronics to allow effectively for optical computers, communication
  1189.    must cross the optical-electronic boundary two or more times.  There
  1190.    are significant cost, performance, reliability, and security benefits
  1191.    for minimizing the number of such crossings.  (As an example of a
  1192.    security benefit, optics is not prone to electronic surveillance or
  1193.    jamming while electronics clearly is, so replacing an optic-
  1194.    electronic-optic node with a pure optic node eliminates that
  1195.    vulnerability point.)
  1196.  
  1197.    The benefits of improved technology in optronics is so great that its
  1198.    application here is purely another motivation for an already active
  1199.    research area (that deserves strong continued support).  Therefore,
  1200.    we focus here in the issue of matching current (and near-term
  1201.    expected) optronics capabilities with network requirements.
  1202.  
  1203.    The first and perhaps greatest area of opportunity is to achieve
  1204.    totally (or largely) photonic switches in the network switching
  1205.    nodes.  That is, most packets would be switched without crossing the
  1206.    optics-electronics boundary at all.  For this to be feasible, the
  1207.    switch must use very simple switching logic, require very little
  1208.    storage and operate on packets of a significant size.  The source-
  1209.    routed packet switches with loopback on blockage of Blazenet
  1210.    illustrate the type of techniques that appear required to achieve
  1211.    this goal.
  1212.  
  1213.    Research is required to investigate the feasibility of optronic
  1214.    implementation of switches.  It appears highly likely that networks
  1215.    will at some point in the future be totally photonically switched,
  1216.    having the impact on networking comparable to the effect of
  1217.    integrated circuits on processors and memories.
  1218.  
  1219.    A next level of focus is to achieve optical switching in the common
  1220.    case in gateways.  One model is a multiprocessor with an optical
  1221.    interconnect.  Packets associated with established paths through the
  1222.    gateway are optically switched and processed through the
  1223.    interconnect.  Other packets are routed to the multiprocessor,
  1224.    crossing into the electronics domain.  Research is required to marry
  1225.    the networking requirements and technology with optronics technology,
  1226.    pushing the state of the art in both areas in the process.
  1227.  
  1228.    Given the long-term presence of the optic-electronic boundary,
  1229.    improvements in technology in this area are also important.  However,
  1230.    it appears that there is already enormous commercial research
  1231.  
  1232.  
  1233.  
  1234. Gigabit Working Group                                          [Page 22]
  1235.  
  1236. RFC 1077                                                   November 1988
  1237.  
  1238.  
  1239.    activity in this area, particularly within the telephone companies.
  1240.    This is another area in which collaborative investigation appears far
  1241.    better than an new independent research effort.
  1242.  
  1243.    VLSI technology is an established technology with active research
  1244.    support.  The GN effort does not appear to require major new
  1245.    initiatives in the VLSI area, yet one should be open to significant
  1246.    novel opportunities not identified here.
  1247.  
  1248.  
  1249.    3.2.6.  High-Speed Transfer Protocols
  1250.  
  1251.  
  1252.    To achieve the desired speeds, it will be necessary to rethink the
  1253.    form of protocols.
  1254.  
  1255.       1.  The simple idea of a stateless gateway must be replaced by a
  1256.           more complex model in which the gateway understands the
  1257.           desired function of the end point and applies suitable
  1258.           optimizations to the flow.
  1259.  
  1260.       2.  If multiplexing is done in the time domain, the elements of
  1261.           multiplexing are probably so small that no significant
  1262.           processing can be performed on each individually.  They must
  1263.           be processed as an aggregate.  This implies that the unit of
  1264.           multiplexing is not the same as the unit of processing.
  1265.  
  1266.       3.  The interfaces between the structural layers of the
  1267.           communication system must change from a simple
  1268.           command/response style to a richer system which includes
  1269.           indications and controls.
  1270.  
  1271.       4.  An approach must be developed that couples the memory
  1272.           management in the host and the structure of the transmitted
  1273.           data, to allow efficient transfers into host memory.
  1274.  
  1275.    The result of rethinking these problems will be a new style of
  1276.    communications and protocols, in which there is a much higher degree
  1277.    of shared responsibility among the components (hosts, switches,
  1278.    gateways).  This may have little resemblance to previous work either
  1279.    in the DARPA or commercial communities.
  1280.  
  1281.  
  1282.    3.3.  High-Speed Host Interfaces
  1283.  
  1284.  
  1285.    As networks get faster, the most significant bottleneck will turn out
  1286.    to be the packet processing overhead in the host.  While this does
  1287.  
  1288.  
  1289.  
  1290. Gigabit Working Group                                          [Page 23]
  1291.  
  1292. RFC 1077                                                   November 1988
  1293.  
  1294.  
  1295.    not restrict the aggregate rates we can achieve over trunks, it
  1296.    prevents delivery of high data rate flows to the host-based
  1297.    applications, which will prevent the development of new applications
  1298.    needing high bandwidth.  The host bottleneck is thus a serious
  1299.    impediment to networked use of supercomputers.
  1300.  
  1301.    To build a GN we need to create new ways for hosts and their high
  1302.    bandwidth peripherals to connect to networks.  We believe that
  1303.    pursuing research in the ways to most effectively isolate host and
  1304.    LAN development paths from the GN is the most productive way to
  1305.    proceed.  By decoupling the development paths, neither is restricted
  1306.    by the momentary performance of capability bottlenecks of the other.
  1307.    The best context in which to view this separation is with the notion
  1308.    of a network front end (NFE).  The NFE can take the electronic input
  1309.    data at many data rates and transform it into gigabit light data
  1310.    appropriately packetized to traverse the GN.  The NFE can accept
  1311.    inputs from many types of gateways, hosts, host peripherals, and LANS
  1312.    and provide arbitration and path set-up facilities as needed.  Most
  1313.    importantly, the NFE can perform protocol arbitration to retain
  1314.    upward compatibility with the existing Internet protocols while
  1315.    enabling those sophisticated network input sources to execute GN
  1316.    specific high-throughput protocols.  Of course, this introduces the
  1317.    need for research into high-speed NFEs to avoid the NFE becoming a
  1318.    bottleneck.
  1319.  
  1320.  
  1321.    3.3.1.  VLSI and Optronics Implementations
  1322.  
  1323.  
  1324.    In a host interface, unless the host is optical (an unlikely prospect
  1325.    in the near-term), the opportunities for optronic support are
  1326.    limited.  In fact, with a serial-to-parallel conversion on reception
  1327.    stepping the clock rate down by a factor of 32 (assuming a 32-bit
  1328.    data path on the host interface), optronic speeds are not required in
  1329.    the immediate future.
  1330.  
  1331.    One exception may be for encryption.  Current VLSI implementations of
  1332.    standard encryption algorithms run in the 10 Mbit/s range.  Optronic
  1333.    implementation of these encryption techniques and encryption
  1334.    techniques specifically oriented to, or taking advantage of, optronic
  1335.    capabilities appears to be an area of some potential (and enormous
  1336.    benefit if achieved).
  1337.  
  1338.    The potential of targeted VLSI research in this area appears limited
  1339.    for similar reasons discussed above with its application in high-
  1340.    speed switching.  The major benefits will arise from work that is
  1341.    well-motivated by other research (such as high-performance
  1342.    parallelism) and by strong commercial interest.  Again, we need to be
  1343.  
  1344.  
  1345.  
  1346. Gigabit Working Group                                          [Page 24]
  1347.  
  1348. RFC 1077                                                   November 1988
  1349.  
  1350.  
  1351.    open to imaginative opportunities not foreseen here while keeping
  1352.    ourselves from being diverted into low-impact research without
  1353.    further insights being put forward.
  1354.  
  1355.  
  1356.    3.3.2.  High-Performance Transport Protocols
  1357.  
  1358.  
  1359.    Current transport protocols exhibit some severe problems for maximal
  1360.    performance, especially for using hardware support.  For example, TCP
  1361.    places the checksum in the packet header, forcing the packet to be
  1362.    formed and read fully before transmission begins.  ISO TP4 is even
  1363.    worse, locating the checksum in a variable portion of the header at
  1364.    an indeterminate offset, making hardware implementation extremely
  1365.    difficult.
  1366.  
  1367.    The current Internet has thrived and grown due to the existence of
  1368.    TCP implementations for a wide variety of classes of host computers.
  1369.    These various TCP implementations achieve robust interoperability by
  1370.    a "least common denominator" approach to features and options.  Some
  1371.    applications have arisen in the current Internet, and analogs can be
  1372.    envisioned for the GN environment, which need qualities of service
  1373.    not generally supported by the ubiquitous generic TCP, and therefore
  1374.    special purpose transport protocols have been developed.  Examples
  1375.    include special purpose transport protocols such as UDP (user
  1376.    datagram protocol), RDP (reliable datagram protocol), LDP
  1377.    (loader/debugger protocol), NETBLT (high-speed block transfer
  1378.    protocol), NVP (network voice protocol) and PVP (packet video
  1379.    protocol).  Efforts are also under way to develop a new generic
  1380.    transport protocol VMTP (versatile message transaction protocol)
  1381.    which will remedy some of deficiencies of TCP, without the need to
  1382.    resort to special purpose protocols for some applications.  Research
  1383.    is needed in this area to understand how transport level protocols
  1384.    should be constructed for a GN which provide adequate qualities of
  1385.    service and ease of implementation.
  1386.  
  1387.    A new transport protocol of reasonable success can be expected to
  1388.    last for ten years more.  Therefore, a new protocol should not be
  1389.    over optimized for current networks and must not ignore the
  1390.    functional deficiencies of current protocols.  These deficiencies are
  1391.    essential to remedy before it is feasible to deploy even current
  1392.    distributed systems technology for military and commercial
  1393.    applications.
  1394.  
  1395.    Forward Error Correction (FEC) is a useful approach when the
  1396.    bandwidth/delay ratio of the physical medium is high, as can be
  1397.    expected in transcontinental photonic links.  A degenerate form of
  1398.    FEC is to simply transmit multiple copies of the data; this allows
  1399.  
  1400.  
  1401.  
  1402. Gigabit Working Group                                          [Page 25]
  1403.  
  1404. RFC 1077                                                   November 1988
  1405.  
  1406.  
  1407.    one to trade bandwidth for delay and reliability, without requiring
  1408.    much intelligence.  In fact, it is generally true that reliability,
  1409.    bandwidth, and delay are interrelated and an improvement in one
  1410.    generally comes at the expense of the others for a given technology.
  1411.    Research is required to find appropriate operating points in networks
  1412.    using transmission components which offer extremely high bandwidth
  1413.    with very good bit-error-rate performance.
  1414.  
  1415.  
  1416.    3.3.3.  Network Adaptors
  1417.  
  1418.  
  1419.    With the promised speed of networks, the future network adaptor must
  1420.    be viewed as a memory interconnect, tying the memory in one host to
  1421.    another, at least if the data rate and the low latency made possible
  1422.    by the network is to be realized at the host-to-host or process-to-
  1423.    process level.  The challenge is too great to be met by just
  1424.    implementing protocols in custom VLSI.
  1425.  
  1426.    Research is required to investigate the impact of network
  1427.    interconnection on a machine architecture and to define and evaluate
  1428.    new network adaptor architectures.  Of key importance is integration
  1429.    of network adaptor into the operating system so that process-to-
  1430.    process communications performance matches that offered by the
  1431.    network.  In particular, we conjecture that the transport level will
  1432.    be implemented largely, if not entirely, in the network adaptor,
  1433.    providing the host with reliable memory-to-memory transfer at memory
  1434.    speeds with a minimum of interrupt processing bus overhead and packet
  1435.    processing.
  1436.  
  1437.    Drawing an analogy to RISC technology again, maximal performance
  1438.    requires a well-designed and coordinated protocol, software, and
  1439.    hardware (network adaptor) design.  Current standard protocols are
  1440.    significantly flawed for hardware compatibility, suggesting a need
  1441.    for considerable further research on high-performance protocol
  1442.    design.
  1443.  
  1444.  
  1445.    3.3.4.  Host Operating System Software
  1446.  
  1447.  
  1448.    Conventionally, communication has been an add-on to an operating
  1449.    system.  With the GN, the network may well become the fastest
  1450.    "peripheral" connected to most nodes.  High-performance process-to-
  1451.    process (or application to application) communication will not be
  1452.    achieved until the operating system is well designed for fast access
  1453.    to and from the network.  For example, incorporating templates of the
  1454.    network packet header directly in the process descriptor may allow a
  1455.  
  1456.  
  1457.  
  1458. Gigabit Working Group                                          [Page 26]
  1459.  
  1460. RFC 1077                                                   November 1988
  1461.  
  1462.  
  1463.    process to initiate communications with minimal overhead.  Similarly,
  1464.    memory mapping can be used to eliminate copies between data arriving
  1465.    from the network and it being delivered to the applications.  With a
  1466.    GN, an extra copy forced by the operating system may easily double
  1467.    the perceived transfer time for a packet between applications.
  1468.  
  1469.    Besides matching data transfer mechanisms, operating systems must be
  1470.    well-matched in security design to that supported by the host
  1471.    interface and network as well.  Otherwise, all but the most trivial
  1472.    additional security actions by the operating system in common case
  1473.    communication can easily eliminate the performance benefits of the
  1474.    GN.  For example, if the host has to do further encryption or
  1475.    decryption, the throughput is likely to be at least halved and the
  1476.    latency doubled.
  1477.  
  1478.    Research effort is required to further refine operating systems for
  1479.    the level of performance offered by the GN.  This effort may well be
  1480.    best realized with coupling existing efforts in distributed systems
  1481.    with the GN activities, as opposed to starting new separate efforts.
  1482.  
  1483.  
  1484.    3.4.  Advanced Network Management Algorithms
  1485.  
  1486.  
  1487.    An important emphasis for research into network management should be
  1488.    on decentralized approaches.  The ratio of propagation delay across
  1489.    the country to data rates in a GN appear to be too great to deal
  1490.    effectively with resource management centrally when traffic load is
  1491.    bursty and unstable (and if it is not, one might argue there is no
  1492.    problem).  In addition, important principles of fault containment and
  1493.    minimal privilege for reliability and security suggest that a
  1494.    centralized management approach is infeasible.  In particular,
  1495.    compromising the security of one portion of the network should not
  1496.    compromise the security of the whole network.  Similarly, a failure
  1497.    or fault should affect at most a local region of the network.
  1498.  
  1499.    The challenge is clearly to provide decentralized management
  1500.    techniques that lead to good global behavior in the normal case and
  1501.    acceptable behavior in expected worst-case failures, traffic
  1502.    variations and security intrusions.
  1503.  
  1504.  
  1505.    3.4.1.  Control Flow vs. Data Flow
  1506.  
  1507.  
  1508.    Network operational communications can be separated into flow of user
  1509.    data and flow of management/control data.  However, the user data
  1510.    must contain some amount of control data.  One question that needs to
  1511.  
  1512.  
  1513.  
  1514. Gigabit Working Group                                          [Page 27]
  1515.  
  1516. RFC 1077                                                   November 1988
  1517.  
  1518.  
  1519.    be explored in light of changes in communications and computing costs
  1520.    and performance is the trade-off between these two flows.  An example
  1521.    of a potential approach is to use data units which contain predefined
  1522.    path indicators.  The switch can perform a simple table look-up which
  1523.    maps the path indicator onto the preferred outbound link and
  1524.    transmits the packet immediately.  There is a path set-up packet
  1525.    which fills in the appropriate tables.  Path set-up occurs before the
  1526.    first data packet flows and then, while data is flowing, to improve
  1527.    the routes during the lifetime of the connection.  This concept has
  1528.    been discussed in the Internet engineering group under the name of
  1529.    soft connections.
  1530.  
  1531.    We note that separating the data flow from the control flow in the GN
  1532.    has security and reliability advantages as well.  We could encrypt
  1533.    most of the packet header to provide confidentiality within the GN
  1534.    and to limit the ability of intruders to perform traffic analysis.
  1535.    And, by separating the control flow, we can encrypt all the control
  1536.    exchanges between switches and the host front ends thereby offering
  1537.    confidentiality and integrity.  No unauthorized entity will be able
  1538.    to alter or examine the control traffic.  By employing a path set-up
  1539.    procedure, we can assure that the GN NFE-to-NFE path is functioning
  1540.    and also include user-specific requirements in the route.  For
  1541.    example, we could request a certain bandwidth allocation and simplify
  1542.    the job of the switches in handling flow control.  We could also set
  1543.    up backup paths in case the output link will be busy for so many
  1544.    microseconds that the packet cannot be stored until the link is
  1545.    freed.
  1546.  
  1547.  
  1548.    3.4.2.  Resource Management Algorithms
  1549.  
  1550.  
  1551.    Most current networks deliver one quality of service.  X.25 networks
  1552.    deliver a reliable byte-stream.  Most LANs deliver a best-effort
  1553.    unreliable service.  There are few networks today that can support
  1554.    multiple types of service, and allocate their resources among them.
  1555.    Indeed, for many networks, such as best-effort unreliable service,
  1556.    there is little management of resources at all.  The next generation
  1557.    of network will require a much more controlled allocation of
  1558.    resources.
  1559.  
  1560.    There will be a much wider range of desired types of service, with
  1561.    current services such as remote procedure call mixing with new
  1562.    services such as video streams.  Unless these are separately
  1563.    recognized and controlled, there is little reason to believe that
  1564.    effective service can be delivered unless the network is very lightly
  1565.    loaded.
  1566.  
  1567.  
  1568.  
  1569.  
  1570. Gigabit Working Group                                          [Page 28]
  1571.  
  1572. RFC 1077                                                   November 1988
  1573.  
  1574.  
  1575.    In order to support multiple types of service, two things must
  1576.    happen, both a change from current practice.  First, the application
  1577.    must describe to the network what type of service is required.
  1578.    Second, the network must use this information to make resource
  1579.    allocation decisions.  Both of these practices present difficulties.
  1580.  
  1581.    Past experience suggests that application code is not prepared to
  1582.    know or specify what service it needs.  By custom, operating systems
  1583.    provide a virtual world, and the applications in this world are
  1584.    unaware of the relation between this and the reality of time and
  1585.    space.  Resource requests must be in real terms.  Allocation of
  1586.    resources in the network is difficult, because it requires that
  1587.    decisions be made in the network, but as network packet throughput
  1588.    increases, there is less time for decisions.
  1589.  
  1590.    The resolution of this latter conflict is to observe that decisions
  1591.    must be made on larger units than the unit of multiplexing such as
  1592.    the packet.  This in turn implies that packets must be visible to the
  1593.    network as being part of a sequence, as opposed to the pure datagram
  1594.    model previously exploited.  As suggested earlier in this report,
  1595.    research is required to support this more complex form of switch
  1596.    without compromising robustness.
  1597.  
  1598.    To permit the application to specify the service it needs, it will be
  1599.    necessary to propose some abstraction of service class.  By clever
  1600.    design of this abstraction, it should be possible to allow the
  1601.    application to describe its needs effectively.  For example, an
  1602.    application such as file transfer or mail has two modes of operation;
  1603.    bulk data transfer and remote procedure call.  The application may
  1604.    not be able to predict when it will be in which mode, but if it just
  1605.    describes both of them, the system may be able to adapt by observing
  1606.    its current operation.
  1607.  
  1608.    Experimentation needs to be done to determine a suitable service
  1609.    specification interface.  This experimentation could be done in the
  1610.    context of the current protocols, and could thus be undertaken at
  1611.    once.
  1612.  
  1613.  
  1614.    3.4.3.  Adaptive Protocols
  1615.  
  1616.  
  1617.    Network operating conditions can vary quickly and over a wide range.
  1618.    This is true of the current Internet, and is likely to affect the GN
  1619.    too.  Protocols that can adapt to changing circumstances would
  1620.    provide more even and robust service than is currently possible.  For
  1621.    example, when error rates increased, a protocol implementation might
  1622.    decide to use smaller packets, thus reducing the burden caused by
  1623.  
  1624.  
  1625.  
  1626. Gigabit Working Group                                          [Page 29]
  1627.  
  1628. RFC 1077                                                   November 1988
  1629.  
  1630.  
  1631.    retransmissions.
  1632.  
  1633.    The environment in which a protocol operates can be described in
  1634.    terms of the service it is getting from the next lower layer.  A
  1635.    protocol implementation can adapt to changes in that service by
  1636.    tuning its internal mechanisms (time-outs, retransmission strategies,
  1637.    etc.).  Therefore, to design adaptive protocols, we must understand
  1638.    the interaction between protocol layers and the mechanisms used
  1639.    within them.  There has been some work done in this area.  For
  1640.    example, the SATNET measurement task force has looked at the
  1641.    interactions between the protocol used by the SIMP, IP, and TCP.
  1642.    What is needed is a more complete characterization of the
  1643.    interactions at various layer boundaries, and the development of
  1644.    appropriate protocol designs and mechanisms to provide for necessary
  1645.    adaptations and renegotiations.
  1646.  
  1647.  
  1648.    3.4.4.  Error Recovery Mechanisms
  1649.  
  1650.  
  1651.    Being large and complex, GNs will experience a variety of faults such
  1652.    as link or nodal failure, excessive buffer overflow due to faulty
  1653.    flow and congestion control, and partial failure of switching fabric.
  1654.    These failures, which also exist in today's networks, will have a
  1655.    stronger effect in GNs where a large amount of data will be "stored"
  1656.    in transit and, to expedite the switching, nodes will apply only
  1657.    minimal processing to the packets traversing them.  In source
  1658.    routing, for example, a link failure may cause the loss of all
  1659.    packets sent until the source is notified about the change in
  1660.    topology.  The longer is the delay in recovering from failures, the
  1661.    higher is the degradation in performance observed by the users.
  1662.  
  1663.    To minimize the effects of failures, GNs will need to employ error
  1664.    recovery mechanisms whereby the network detects failures and error
  1665.    conditions, reconfigures itself to adapt to the new network state,
  1666.    and notifies peripheral devices of the new configuration.  Such
  1667.    protocols, which have to be developed, will respond quickly, will be
  1668.    decentralized or distributed to minimize the possibility of fatal
  1669.    failures, and will complement, rather than replicate, the error
  1670.    correction mechanisms of the end-to-end protocols, and the two must
  1671.    operate in coordinated manner.  To this end, the peripheral devices
  1672.    will have to be knowledgeable about the intranet recovery mechanisms
  1673.    and interact continuously with them to minimize the effect on the
  1674.    connections they manage.
  1675.  
  1676.  
  1677.  
  1678.  
  1679.  
  1680.  
  1681.  
  1682. Gigabit Working Group                                          [Page 30]
  1683.  
  1684. RFC 1077                                                   November 1988
  1685.  
  1686.  
  1687.    3.4.5.  Flow Control
  1688.  
  1689.  
  1690.    As networks become faster, two related problems arise.  First,
  1691.    existing flow control mechanisms such as windows do not work well,
  1692.    because the window must be opened to such an extent to achieve
  1693.    desired bandwidth that effective flow control cannot be achieved.
  1694.    Second, especially for long-haul networks, the larger number of bits
  1695.    in transit at one time becomes so large that most computer messages
  1696.    will fit into one window.  This means that traditional congestion
  1697.    control schemes will cease to work well.
  1698.  
  1699.    What is needed is a combination of two approaches, both new.  First,
  1700.    for messages that are small (most messages generated by computers
  1701.    today will be small, since they will fit into one round-trip time of
  1702.    future networks), open-loop controls on flow and congestion are
  1703.    needed.  For longer messages (voice or video streams, for example),
  1704.    some explicit resource commitment will be required.
  1705.  
  1706.  
  1707.    3.4.6.  Latency Control and Real-Time Operations
  1708.  
  1709.  
  1710.    Currently, there are several distinct approaches to latency control.
  1711.    First, there are some networks which are physically short, more like
  1712.    multiprocessor buses.  Applications in these networks are built
  1713.    assuming that delays will be short.
  1714.  
  1715.    Second, there are networks where the physical length is not
  1716.    constrained by the design and may differ by orders of magnitude,
  1717.    depending on the scope of the network.  Most general purpose networks
  1718.    fall in this category.  In these networks, one of two things happens.
  1719.    Either the application takes special steps to deal with variable
  1720.    latency, such as echo suppression in voice networks, or these
  1721.    applications are not supported.
  1722.  
  1723.    For most applications today, the latency in the network is not an
  1724.    obvious issue so long as the network is not overloaded (which leads
  1725.    to losses and long queues), because the protocol overhead masks the
  1726.    variation in the network latency.  This balance will change.  The
  1727.    latency due to the speed of light will obviously remain the same, but
  1728.    the overhead will drop (of necessity if we are to achieve high
  1729.    performance) which will leave speed of light and queueing as the most
  1730.    critical sources of delay.
  1731.  
  1732.    This conclusion implies that if queueing delay can be controlled, it
  1733.    will be possible to build networks with stable and controlled
  1734.    latency.  If applications exist that require this class of service,
  1735.  
  1736.  
  1737.  
  1738. Gigabit Working Group                                          [Page 31]
  1739.  
  1740. RFC 1077                                                   November 1988
  1741.  
  1742.  
  1743.    it can be supported.  Either the network must be underloaded, so that
  1744.    queues do not develop at all, or a specific class of service must be
  1745.    supported in which resources are allocated to stabilize the delay.
  1746.  
  1747.    If this service is provided, it will still leave the application with
  1748.    delays that can vary by several orders of magnitude, depending on the
  1749.    physical size of the network.  Research at the application level will
  1750.    be required to see how applications can be designed to cope with this
  1751.    variation.
  1752.  
  1753.  
  1754.    3.4.7.  High-Speed Internetworking and Administrational Domains
  1755.  
  1756.  
  1757.    Internetworking recognized that the value of communication services
  1758.    increases significantly with wider interconnection but ignored
  1759.    management and the role of administrations.  As a consequence we see
  1760.    that:
  1761.  
  1762.       1.  The Internet is more or less unmanageable, as evidenced by
  1763.           performance, reliability, and security problems.
  1764.  
  1765.       2.  The Internet is being stressed by administrators that are
  1766.           building networks to match their organization rather than the
  1767.           geography.  An example is a set of Ethernets at different
  1768.           company locations operating as a single Internet network but
  1769.           geographically dispersed and connected by satellite or leased
  1770.           lines.
  1771.  
  1772.    The next generation of internetworking must focus on administration
  1773.    and management.  Internetworking must support cohesion within an
  1774.    administration and a healthy separation between administrations.  To
  1775.    illustrate by analogy, the American and Soviet embassies in Mexico
  1776.    City are geographically closer to each other than to their respective
  1777.    home countries but further in administrational distance, including
  1778.    security, accounting, etc.  The emerging revolution in WANs makes
  1779.    this issue that much more critical.  The amount of communication to
  1780.    exchange the state of systems is bound to increase enormously.  The
  1781.    potential cost of failures and security violations is frightening.
  1782.  
  1783.    A promising approach appears to be high-level gateways that guard
  1784.    between administrations and require negotiations to set up access
  1785.    paths between administrations.  These paths are set up, and labeled
  1786.    with agreements on authorization, security, accounting, and possible
  1787.    resource limits.  These administrative virtual circuits provide
  1788.    transparency to the physical and geographical interconnection, but
  1789.    need not support more than datagram packet delivery.  One view is
  1790.    that of communication contracts with high-level gateways acting as
  1791.  
  1792.  
  1793.  
  1794. Gigabit Working Group                                          [Page 32]
  1795.  
  1796. RFC 1077                                                   November 1988
  1797.  
  1798.  
  1799.    contract monitors at each end.  The key is the focus on controlled
  1800.    interadministrational connectivity, not the conventional protocol
  1801.    concerns.
  1802.  
  1803.    Focus is required on developing an (inter)network management
  1804.    architecture and the specifics of high-level gateways.  The
  1805.    structures of such gateways will have to take advantage of advances
  1806.    in multi-processor architectures to handle the processing load.
  1807.    Moreover, a key issue is being able to optimize communication between
  1808.    administrations once the contract is in place, but without losing
  1809.    control.  Related is the issue of allowing high-speed interconnection
  1810.    within a single administration, although geographical dispersed.
  1811.    Another issue is fault-tolerance.  High-level gateways contain state
  1812.    information whose loss typically disrupts communication.  How does
  1813.    one minimize this problem?
  1814.  
  1815.    A key goal of these administrational gateways has to be failure
  1816.    containment: How to protect against external (to administration)
  1817.    problems and how to prevent local problems imposing liability on
  1818.    others.  A particular area of concern is the self-organizing problems
  1819.    of large-scale systems, observed by Van Jacobson in the Internet.
  1820.    Gateways must serve to damp out oscillations and control wide load
  1821.    swings.  Rate control appears to be a key area to investigate as a
  1822.    basis for buffer management and for congestion control, as well as to
  1823.    control offered load.
  1824.  
  1825.    Given the speed of new networks, and the sophistication of the
  1826.    gateways suggested above, another key area to investigate is the
  1827.    provision of high-speed network interface adaptors.
  1828.  
  1829.  
  1830.    3.4.8.  Policy-Based Algorithms
  1831.  
  1832.  
  1833.    Networks of today generally select routes based on minimizing some
  1834.    measure such as delay.  However, in the real world, route selection
  1835.    will commonly be constrained at the global level by policy issues,
  1836.    such as access rights to resources and accounting and billing for
  1837.    usage.
  1838.  
  1839.    It is difficult for connectionless protocols such as Internet to deal
  1840.    with policy controls, because a lack of state in the gateway implies
  1841.    that a separate policy decision must be made for each packet in
  1842.    isolation.  As networks get faster, the cost of this processing will
  1843.    be intolerable.  One possible approach, discussed above, is to move
  1844.    to a more sophisticated model in which there is knowledge in the
  1845.    gateways of the ongoing flows.  Alternatively, it may be possible to
  1846.    design gateways that simply cache recent policy evaluations and apply
  1847.  
  1848.  
  1849.  
  1850. Gigabit Working Group                                          [Page 33]
  1851.  
  1852. RFC 1077                                                   November 1988
  1853.  
  1854.  
  1855.    them to successive packets.
  1856.  
  1857.    Routing based on policy is particularly difficult because a route
  1858.    must be globally consistent to be useful; otherwise it may loop.
  1859.    This implies that the every policy decision must be propagated
  1860.    globally.  Since there can be expected to be a large number of
  1861.    policies, this global passing of information might easily lead to an
  1862.    information explosion.
  1863.  
  1864.    There are at least two solutions.  One is to restrict the possible
  1865.    classes of policy.  Another is to use some form of source route, so
  1866.    that the route consistent with some set of policies is computed at
  1867.    one point only, and then attached to the packet.  Both of these
  1868.    approaches have problems.  A two-pronged research program is needed,
  1869.    in which mechanisms are proposed, and at the same time the needed
  1870.    policies are defined.
  1871.  
  1872.    The same trade-off can be seen for accounting and billing.  A single
  1873.    accounting metric, such as "bytes times distance", could be proposed.
  1874.    This might be somewhat simple to implement, but would not permit the
  1875.    definition of individual billing policies, as is now done in the
  1876.    parts of the telephone system.  The current connectionless transport
  1877.    architectures such as TCP/IP or the connectionless ISO configuration
  1878.    using TP4 do not have good tools for accounting for traffic, or for
  1879.    restricting traffic from certain resources.  Building these tools is
  1880.    difficult in a connectionless environment, because an accounting or
  1881.    control facility must deal with each packet in isolation, which
  1882.    implies a significant processing burden as part of packet forwarding.
  1883.    This burden is an increasing problem as switches are expected to
  1884.    operate faster.
  1885.  
  1886.    The lack of these tools is proving a significant problem for network
  1887.    design.  Not only are accounting and control needed to support
  1888.    management requirements, they are needed as a building block to
  1889.    support enforcement of such things as multiple qualities of service,
  1890.    as discussed above.
  1891.  
  1892.    Network accounting is generally considered to be simply a step that
  1893.    leads to billing, and thus is often evaluated in terms of how simple
  1894.    or difficult it will be to implement.  Yet an accounting and billing
  1895.    procedure is a mechanism for implementing a policy considered to be
  1896.    desirable for reasons beyond the scope of accounting per se.  For
  1897.    example, a policy might be established either to encourage or
  1898.    discourage network use, while fully recovering operational cost.  A
  1899.    policy of encouraging use could be implemented by a relatively high
  1900.    monthly attachment charge and a relatively low per-packet charge.  A
  1901.    policy of discouraging use could be implemented by a low monthly
  1902.    charge and a high per-packet charge.
  1903.  
  1904.  
  1905.  
  1906. Gigabit Working Group                                          [Page 34]
  1907.  
  1908. RFC 1077                                                   November 1988
  1909.  
  1910.  
  1911.    Network administrators have a relatively small number of variables
  1912.    with which to implement policy objectives.  Nevertheless, these
  1913.    variables can be combined in a number of innovative ways.  Some of
  1914.    the possibilities include:
  1915.  
  1916.       1.  Classes of users (e.g., large or small institutions, for-
  1917.           profit or non-profit).
  1918.  
  1919.       2.  Classes of service.
  1920.  
  1921.       3.  Time varying (e.g., peak and off-peak).
  1922.  
  1923.       4.  Volume (e.g., volume discounts, or volume surcharges).
  1924.  
  1925.       5.  Access charges (e.g., per port, or port * [bandwidth of
  1926.           port]).
  1927.  
  1928.       6.  Distance (e.g., circuit-miles, airline miles, number of hops).
  1929.  
  1930.    Generally, an accounting procedure can be developed to support
  1931.    voluntary user cooperation with almost any single policy objective.
  1932.    Difficulties most often arise when there are multiple competing
  1933.    policy objectives, or when there is no clear policy at all.
  1934.  
  1935.    Another aspect of accounting and billing procedures which must be
  1936.    carefully considered is the cost of accumulating and processing the
  1937.    data on which billing is based.  Of particular concern is collection
  1938.    of detailed data on a per-packet basis.  As network circuit data
  1939.    rates increase, the number of instructions which must be executed on
  1940.    a per-packet basis can become the limiting factor in system
  1941.    throughput.  Thus, it may be appropriate to prefer accounting and
  1942.    billing policies and procedures which minimize the difficulty of
  1943.    collecting data, even if this approach requires a compromise of other
  1944.    objectives.  Similarly, node memory required for data collection and
  1945.    any network bandwidth required for transmission of the data to
  1946.    administrative headquarters are factors which must be traded off
  1947.    against the need to process user packets.
  1948.  
  1949.  
  1950.    3.4.9.  Priority and Preemption
  1951.  
  1952.  
  1953.    The GN should support multiple levels of priority for traffic and the
  1954.    preemption of network resources for higher priority use.  Network
  1955.    control traffic should be given the highest priority to ensure that
  1956.    it is able to pass through the network unimpeded by congestion caused
  1957.    by user-level traffic.  There may be additional military uses for
  1958.    multiple levels of priority which correspond to rank or level of
  1959.  
  1960.  
  1961.  
  1962. Gigabit Working Group                                          [Page 35]
  1963.  
  1964. RFC 1077                                                   November 1988
  1965.  
  1966.  
  1967.    importance of a user or the mission criticality of some particular
  1968.    data.
  1969.  
  1970.    The use of and existence of priority levels may be different for
  1971.    different types of traffic.  For example, datagram traffic may not
  1972.    have multiple priority levels.  Because the network's transmission
  1973.    speed is so high and traffic bursts may be short, it may not make
  1974.    sense to do any processing in the switches to deal with different
  1975.    priority levels.  Priority will be more important for flow- (or
  1976.    soft-connection-) oriented data or hard connections in terms of
  1977.    permitting higher priority connections to be set up ahead of lower
  1978.    priority connections.  Preemption will permit requests for high
  1979.    priority connections to reclaim network resources currently in use by
  1980.    lower priority traffic.
  1981.  
  1982.    Networks such as the Wideband Satellite Network, which supports
  1983.    datagram and stream traffic, implement four priority levels for
  1984.    traffic with the highest reserved for network control functions and
  1985.    the other three for user traffic.  The Wideband Network supports
  1986.    preemption of lower priority stream allocations by higher priority
  1987.    requests.  An important component of the use of priority and
  1988.    preemption is the ability to notify users when requests for service
  1989.    have been denied, or allocations have been modified or disrupted.
  1990.    Such mechanisms have been implemented in the Wideband Network for
  1991.    streams and dynamic multicast groups.
  1992.  
  1993.    Priority and preemption mechanisms for a GN will have to be
  1994.    implemented in an extremely simple way so that they can take effect
  1995.    very quickly.  It is likely that they will have to built into the
  1996.    hardware of the switch fabric.
  1997.  
  1998.  
  1999.    3.5.  User and Network Services
  2000.  
  2001.  
  2002.    As discussed in Section 2 above, there will need to be certain
  2003.    services provided as part of the network operation to the users
  2004.    (people) themselves and to the machines that connect to the network.
  2005.    These services, which include such capabilities as white and yellow
  2006.    pages (allowing users to determine what the appropriate network
  2007.    identification is for other users and for network-available computing
  2008.    resources) and distributed fault identification and isolation, are
  2009.    needed in current networks and will continue to be required in the
  2010.    networks of the future.  The speed of the GN will serve to accentuate
  2011.    this requirement, but at the same time will allow for new
  2012.    architectures to be put in place for such services.  For example,
  2013.    Ethernet speeds in the local environment have allowed for more usable
  2014.    services to be provided.
  2015.  
  2016.  
  2017.  
  2018. Gigabit Working Group                                          [Page 36]
  2019.  
  2020. RFC 1077                                                   November 1988
  2021.  
  2022.  
  2023.    3.5.1.  Impact of High Bandwidth
  2024.  
  2025.  
  2026.    One issue that will need to be addressed is the impact on the user of
  2027.    such high-bandwidth capabilities.  Users are already becoming
  2028.    saturated by information in the modern information-rich environment.
  2029.    (Many of us receive more than 50 electronic mail messages each day,
  2030.    each requiring some degree of human attention.) Methods will be
  2031.    needed to allow users to cope with this ever-expanding access to
  2032.    data, or we will run the risk of users turning back to the relative
  2033.    peace and quiet of the isolated office.
  2034.  
  2035.  
  2036.    3.5.2.  Distributed Network Directory
  2037.  
  2038.  
  2039.    A distributed network directory can support the user-level directory
  2040.    services and the lower-level name-to-address mapping services
  2041.    described elsewhere in this report.  It can also support distributed
  2042.    systems and network management facilities by storing additional
  2043.    information about named objects.  For example, the network directory
  2044.    might store node configurations or security levels.
  2045.  
  2046.    Distributing the directory eases and decentralizes the administrative
  2047.    burdens and provides a more robust and survivable implementation.
  2048.  
  2049.    One approach toward implementing a distributed network directory
  2050.    would be to base it upon the CCITT X.500/ISO DIS 9594 standard.  This
  2051.    avoids starting from ground zero and has the advantage of
  2052.    facilitating interoperability with other communications networks.
  2053.    However, research and development will be required even if this path
  2054.    is chosen.
  2055.  
  2056.    One area in which research and development are required is in the
  2057.    services supplied by the distributed network directory.  The X.500
  2058.    standard is very general and powerful, but so far specific provisions
  2059.    have been made only for storing information about network users and
  2060.    applications.  As mentioned elsewhere, multilevel security is not
  2061.    addressed by X.500, and the approach taken toward authentication must
  2062.    be carefully considered in view of DoD requirements.  Also, X.500
  2063.    assumes that administration of the directory will be done locally and
  2064.    without the need for standardization; this may not be true of GN or
  2065.    the larger national research network.
  2066.  
  2067.    The model and algorithms used by a distributed network directory
  2068.    constitute a second area of research.  The model specified by X.500
  2069.    must be extended into a framework that provides the necessary
  2070.    flexibility in terms of services, responsiveness, data management
  2071.  
  2072.  
  2073.  
  2074. Gigabit Working Group                                          [Page 37]
  2075.  
  2076. RFC 1077                                                   November 1988
  2077.  
  2078.  
  2079.    policies, and protocol layer utilization.  Furthermore, the internal
  2080.    algorithms and mechanisms of X.500 must be extended in a number of
  2081.    areas; for example, to support redundancy of the X.500 database,
  2082.    internal consistency checking, fuller sharing of information about
  2083.    the distribution of data, and defined access-control mechanisms.
  2084.  
  2085.  
  2086.    4.  Avenues of Approach
  2087.  
  2088.  
  2089.    Ongoing research and commercial activities provide an opportunity for
  2090.    more rapidly attacking some of the above research issues.  At the
  2091.    same time, there needs to be attention paid to the overall technical
  2092.    approach used to allow multiple potential solutions to be explored
  2093.    and allow issues to be attacked in parallel.
  2094.  
  2095.  
  2096.    4.1.  Small Prototype vs. Nationwide Network
  2097.  
  2098.  
  2099.    The central question is how far to jump, and how far can the current
  2100.    approaches get.  That is, how far will connectionless network service
  2101.    get us, how far will packet switching get us, and how far do we want
  2102.    to go.  If our goal is a Gbit/s net, then that is what we should
  2103.    build.  Building a 100 Mbit/s network to achieve a GN is analogous to
  2104.    climbing a tree to get to the moon.  It may get you closer, but it
  2105.    will never get you there.
  2106.  
  2107.    There are currently some network designs which can serve as the basis
  2108.    for a GN prototype.  The next step is some work by experts in
  2109.    photonics and possibly high-speed electronics to explore ease of
  2110.    implementation.  Developing a prototype 3-5 node network at a Gbit/s
  2111.    data rate is realistic at this point and would demonstrate wide-area
  2112.    (40 km or more) Gbit/s networking.
  2113.  
  2114.    DARPA should consider installing a Gbit/s cross-country set of
  2115.    connected links analogous to the NSF backbone in 2 years.  A Gbit/s
  2116.    link between the east and west coasts would open up a whole new
  2117.    generation of (C3I), distributed computing, and parallel computing
  2118.    research possibilities and would reestablish DARPA as the premier
  2119.    network research funding agency in the country.  This will require
  2120.    getting "dark" fiber from one or more of the common carriers and some
  2121.    collaboration with these organizations on repeaters, etc.  With this
  2122.    collaboration, the time to a commercial network in the Gbit/s range
  2123.    would be substantially reduced, and the resulting nationwide GN would
  2124.    give the United States an enormous technical and economic advantage
  2125.    over countries without it.
  2126.  
  2127.  
  2128.  
  2129.  
  2130. Gigabit Working Group                                          [Page 38]
  2131.  
  2132. RFC 1077                                                   November 1988
  2133.  
  2134.  
  2135.    Demonstrating a high-bandwidth WAN is not enough, however.  As one
  2136.    can see from the many research issues identified above, it will be
  2137.    necessary to pursue via study and experiment the issues involved in
  2138.    interconnecting high-bandwidth networks into a high-bandwidth
  2139.    internet.  These experiments can be done through use of a new
  2140.    generation of internet, even if it requires starting at lower speeds
  2141.    (e.g., T1 through 100 Mbit/s).  Appropriate care must be given,
  2142.    however, to assure that the capabilities that are demonstrated are
  2143.    applicable to the higher bandwidths (Gbit/s) as they emerge.
  2144.  
  2145.  
  2146.    4.2.  Need for Parallel Efforts/Approaches
  2147.  
  2148.  
  2149.    Parallel efforts will therefore be required for two major reasons.
  2150.    First is the need to pursue alternative approaches (e.g., different
  2151.    strategies for high-bandwidth switching, different addressing
  2152.    techniques, etc).  This is the case for most research programs, but
  2153.    it is made more difficult here by the costs of prototyping.  Thus, it
  2154.    is necessary that appropriate review take place in the decisions as
  2155.    to which efforts are supported through prototyping.
  2156.  
  2157.    In addition, it will be necessary to pursue the different aspects of
  2158.    the program in parallel.  It will not be possible to wait until the
  2159.    high-bandwidth network is available before starting on prototyping
  2160.    the high-bandwidth internet.  Thus, a phased and evolutionary
  2161.    approach will be needed.
  2162.  
  2163.  
  2164.    4.3.  Collaboration with Common Carriers
  2165.  
  2166.  
  2167.    Computer communication networks in the United States today
  2168.    practically ignore the STN (the Switched Telephone Network), except
  2169.    for buying raw bandwidth through it.  However, advances in network
  2170.    performance are based on improvements in the underlying communication
  2171.    media, including satellite communication, fiber optics, and photonic
  2172.    switching.
  2173.  
  2174.    In the past we used "their" transmission under "our" switching.  An
  2175.    alternative approach is to utilize the common-carrier switching
  2176.    capabilities as an integral part of the networking architecture.  We
  2177.    must take an objective scientific and economic look and reevaluate
  2178.    this question.
  2179.  
  2180.    Another place for cooperation with the common carriers is in the area
  2181.    of network addressing.  Their addressing scheme ("numbering plan")
  2182.    has a few advantages such as proven service to 300 million users [4].
  2183.  
  2184.  
  2185.  
  2186. Gigabit Working Group                                          [Page 39]
  2187.  
  2188. RFC 1077                                                   November 1988
  2189.  
  2190.  
  2191.    On the other hand, the common carriers have far fewer administrative
  2192.    domains (area codes) than the current plethora of locally
  2193.    administered local area networks in the internet system.
  2194.  
  2195.    It is likely that future networks will eventually be managed and
  2196.    operated by commercial communications providers.  A way to maximize
  2197.    technology transfer from the research discussed here to the
  2198.    marketplace is to involve the potential carriers from the start.
  2199.    However, it is not clear that the goals of commercial communications
  2200.    providers, who have typically been most interested in meeting the
  2201.    needs of 90+ percent of the user base, will be compatible with the
  2202.    goals of the research described here.  Thus, while we recommend that
  2203.    the research program involve an appropriate amalgam of academia and
  2204.    industry, paying particular attention to involvement of the potential
  2205.    system developers and operators, we also caution that the specific
  2206.    and unique goals of the DARPA program must be retained.
  2207.  
  2208.  
  2209.    4.4.  Technology Transfer
  2210.  
  2211.  
  2212.    As we said above, it is our belief that future networks will
  2213.    ultimately be managed and operated by commercial communications
  2214.    providers.  (Note that this may not be the common carriers as we know
  2215.    them today, but may be value-added networks using common carrier
  2216.    facilities.) The way to assure technology transfer, in our belief, is
  2217.    to involve the potential system developers from the start.  We
  2218.    therefore believe that the research program would benefit from an
  2219.    appropriate amalgam of university and industry, with provision for
  2220.    close involvement of the potential system developers and operators.
  2221.  
  2222.  
  2223.    4.5.  Standards
  2224.  
  2225.  
  2226.    The Internet program was a tremendous success in influencing national
  2227.    and international standards.  While there were changes to the
  2228.    protocols, the underlying technology and approaches used by CCITT and
  2229.    ISO in the standardization of packet-switched networks clearly had
  2230.    its roots in the DARPA internet.  Nevertheless, this has had some
  2231.    negative impact on the research program, as the evolution of the
  2232.    standards led to pressure to adopt them in the research environment.
  2233.  
  2234.    Thus, it appears that there is a "catch-22" here.  It is desirable
  2235.    for the technology base developed in the research program to have
  2236.    maximal impact on the standards activities.  This is expedited by
  2237.    doing the research in the context of the standards environment.
  2238.    However, standards by their very nature will always lag behind the
  2239.  
  2240.  
  2241.  
  2242. Gigabit Working Group                                          [Page 40]
  2243.  
  2244. RFC 1077                                                   November 1988
  2245.  
  2246.  
  2247.    research environment.
  2248.  
  2249.    The only reasonable approach, therefore, appears to be an occasional
  2250.    "checkpointing" of the research environment, where the required
  2251.    conversions take place to allow a new plateau of standards to be used
  2252.    for future evolution and research.  A good example is conducting
  2253.    future research in mail using X.400 and X.500 where possible.
  2254.  
  2255.  
  2256.    5.  Conclusions
  2257.  
  2258.  
  2259.    We hope that this document has provided a useful compendium of those
  2260.    research issues critical to achieving the FCCSET phase III
  2261.    recommendations.  These problems interact in a complex way.  If the
  2262.    only goal of a new network architecture was high speed, reasonable
  2263.    solutions would not be difficult to propose.  But if one must achieve
  2264.    higher speeds while supporting multiple services, and at the same
  2265.    time support the establishment of these services across
  2266.    administrative boundaries, so that policy concerns (e.g., access
  2267.    control) must be enforced, the interactions become complex.
  2268.  
  2269.  
  2270.  
  2271.  
  2272.  
  2273.  
  2274.  
  2275.  
  2276.  
  2277.  
  2278.  
  2279.  
  2280.  
  2281.  
  2282.  
  2283.  
  2284.  
  2285.  
  2286.  
  2287.  
  2288.  
  2289.  
  2290.  
  2291.  
  2292.  
  2293.  
  2294.  
  2295.  
  2296.  
  2297.  
  2298. Gigabit Working Group                                          [Page 41]
  2299.  
  2300. RFC 1077                                                   November 1988
  2301.  
  2302.  
  2303.                                  APPENDIX
  2304.  
  2305. A. Current R and D Activities
  2306.  
  2307.    In this appendix, we provide pointers to some ongoing activities in
  2308.    the research and development community of which the group was aware
  2309.    relevant to the goal of achieving the GN.  In some cases, a short
  2310.    abstract is provided of the research.  Neither the order of the
  2311.    listing (which is random) nor the amount of detail provided is meant
  2312.    to indicate in any way the significance of the activity.  We hope
  2313.    that this set of pointers will be useful to anyone who chooses to
  2314.    pursue the research issues discussed in this report.
  2315.  
  2316.       1.  Grumman (at Bethpage) is working on a three-year DARPA
  2317.           contract, started in January 1988 to develop a 1.6 Gbit/s LAN,
  2318.           for use on a plane or ship, or as a "building block".  It is
  2319.           really raw transport capacity running on two fibers in a
  2320.           token-ring like mode.  First milestone (after one year?) is to
  2321.           be a 100 Mbit/s demonstration.
  2322.  
  2323.       2.  BBN Laboratories, as part of its current three-year DARPA
  2324.           Network-Oriented Systems contract, has proposed design
  2325.           concepts for a 10-100 Gbit/s wide area network.  Work under
  2326.           this effort will include wavelength division multiplexing,
  2327.           photonic switching, self-routing packets, and protocol design.
  2328.  
  2329.       3.  Cheriton (Stanford) research on Blazenet, a high-bandwidth
  2330.           network using photonic switching.
  2331.  
  2332.       4.  Acampora (Bell Labs) research on the use of wavelength
  2333.           division multiplexing for building a shared optical network.
  2334.  
  2335.       5.  Yeh is reserching a VLSI approach to building high-bandwidth
  2336.           parallel processing packet switch.
  2337.  
  2338.       6.  Bell Labs is working on a Metropolitan Area Network called
  2339.           "Manhattan Street Net."  This work, under Dr. Maxemchuck, is
  2340.           similar to Blazenet.  It is in the prototype stage for a small
  2341.           number of street intersections; ultimately it is meant to be
  2342.           city-wide.  Like Blazenet, is uses photonic switching 2 x 2
  2343.           lithium niobate block switches.
  2344.  
  2345.       7.  Ultra Network Technologies is a Silicon Valley company which
  2346.           has a (prototype) Gbit/s fiber link which connects backplanes.
  2347.           This is based on the ISO-TP4 transport protocol.
  2348.  
  2349.       8.  Jonathan Turner, Washington University, is working on a
  2350.           Batcher-Banyan Multicast Net, based on the "SONET" concept,
  2351.  
  2352.  
  2353.  
  2354. Gigabit Working Group                                          [Page 42]
  2355.  
  2356. RFC 1077                                                   November 1988
  2357.  
  2358.  
  2359.           which provides 150 Mbit/s per pipe.
  2360.  
  2361.       9.  David Sincowskie, Bellcore, is working with Batcher-Banyan
  2362.           design and has working 32x32 switches.
  2363.  
  2364.       10. Stratacom has a commercial product which is really a T1 voice
  2365.           switch implemented internally by a packet switch, where the
  2366.           packet is 192 bits (T1 frame).  This switch can pass 10,000
  2367.           packets per second.
  2368.  
  2369.       11. Stanford NAB provides 30-50 Mbit/s throughput on 100 Mbit/s
  2370.           connection using Versatile Message Transaction Protocol (VMTP)
  2371.           [see RFC 1045]
  2372.  
  2373.       12. The December issue of IEEE Journal on Selected Areas in
  2374.           Communications, provides much detail concerning interconnects.
  2375.  
  2376.       13. Ultranet Technology has a 480 Mbit/s connection using modified
  2377.           ISO TP4.
  2378.  
  2379.       14. At MIT, Dave Clark has an architecture proposal of interest.
  2380.  
  2381.       15. At CMU, the work of Eric Cooper is relevant.
  2382.  
  2383.       16. At Protocol Engines, Inc., Greg Chesson is working on an XTP-
  2384.           based system.
  2385.  
  2386.       17. Larry Landweber at Wisconsin University is doing relevant
  2387.           work.
  2388.  
  2389.       18. Honeywell is doing relevant work for NASA.
  2390.  
  2391.       19. Kung at CMU is working on a system called "Nectar" based on a
  2392.           STARLAN on fiber connecting dissimilar processors.
  2393.  
  2394.       20. Burroughs (now Unisys) has some relevant work within the IEEE
  2395.           802.6 committee.
  2396.  
  2397.       21. Bellcore work in "Switched Multimedia Datanet Service" (SMDS)
  2398.           is relevant (see paper supplied by Dave Clark).
  2399.  
  2400.       22. FDDI-2, a scheme for making TDMA channel allocations at 200
  2401.           Mbit/s.
  2402.  
  2403.       23. NRI, Kahn-Farber Proposal to NSF, is a paper design for high-
  2404.           bandwidth network.
  2405.  
  2406.       24. Barry Goldstein work, IBM-Yorktown.
  2407.  
  2408.  
  2409.  
  2410. Gigabit Working Group                                          [Page 43]
  2411.  
  2412. RFC 1077                                                   November 1988
  2413.  
  2414.  
  2415.       25. Bell Labs S-Net, 1280 Mbit/s prototype.
  2416.  
  2417.       26. Fiber-LAN owned by Bell South and SECOR, a pre-prototype 575
  2418.           Mbit/s Metro Area Net.
  2419.  
  2420.       27. Bellcore chip implementation of FASTNET (1.2 Gbit/s).
  2421.  
  2422.       28. Scientific Computer Systems, San Diego, 1.4 Gbit/s prototype.
  2423.  
  2424.       29. BBN Monarch Switch, Space Division pre-prototype, chips being
  2425.           fabricated, 64 Mbit/s per path.
  2426.  
  2427.       30. Proteon, 80 Mbit/s token ring.
  2428.  
  2429.       31. Toronto University, 150 Mbit/s "tree"--- really a LAN.
  2430.  
  2431.       32. NSC Hyperchannel II, reputedly available at 250 Mbit/s.
  2432.  
  2433.       33. Tobagi at Stanford working on EXPRESSNET; not commercially
  2434.           available.
  2435.  
  2436.       34. Columbia MAGNET-- 150 Mbit/s.
  2437.  
  2438.       35. Versatile Message Transaction Protocol (VMTP).
  2439.  
  2440.       36. ST integrated with IP.
  2441.  
  2442.       37. XTP (Chesson).
  2443.  
  2444.       38. Stanford Transport Gateway.
  2445.  
  2446.       39. X.25/X.75.
  2447.  
  2448.       40. Work of the Internet Activities Board.
  2449.  
  2450.  
  2451.  
  2452.  
  2453.  
  2454.  
  2455.  
  2456.  
  2457.  
  2458.  
  2459.  
  2460.  
  2461.  
  2462.  
  2463.  
  2464.  
  2465.  
  2466. Gigabit Working Group                                          [Page 44]
  2467.  
  2468. RFC 1077                                                   November 1988
  2469.  
  2470.  
  2471. B. Gigabit Working Group Members
  2472.  
  2473. Member                  Affiliation
  2474.  
  2475. Gordon Bell             Ardent Computers
  2476. Steve Blumenthal        BBN Laboratories
  2477. Vint Cerf               Corporation for National Research Initiatives
  2478. David Cheriton          Stanford University
  2479. David Clark             Massachusetts Institute of Technology
  2480. Barry Leiner (Chairman) Research Institute for Advanced Computer Science
  2481. Robert Lyons            Defense Communication Agency
  2482. Richard Metzger         Rome Air Development Center
  2483. David Mills             University of Delaware
  2484. Kevin Mills             National Bureau of Standards
  2485. Chris Perry             MITRE
  2486. Jon Postel              USC Information Sciences Institute
  2487. Nachum Shacham          SRI International
  2488. Fouad Tobagi            Stanford University
  2489.  
  2490.  
  2491.  
  2492.  
  2493.  
  2494.  
  2495.  
  2496.  
  2497.  
  2498.  
  2499.  
  2500.  
  2501.  
  2502.  
  2503.  
  2504.  
  2505.  
  2506.  
  2507.  
  2508.  
  2509.  
  2510.  
  2511.  
  2512.  
  2513.  
  2514.  
  2515.  
  2516.  
  2517.  
  2518.  
  2519.  
  2520.  
  2521.  
  2522. Gigabit Working Group                                          [Page 45]
  2523.  
  2524. RFC 1077                                                   November 1988
  2525.  
  2526.  
  2527. End Notes
  2528.  
  2529.      [1] Workshop on Computer Networks, 17-19 February 1987, San Diego,
  2530.          CA.
  2531.  
  2532.      [2] "A Report to the Congress on Computer Networks to Support
  2533.          Research in the United States: A Study of Critical Problems and
  2534.          Future Options", White House Office of Scientific and Technical
  2535.          Policy (OSTP), November 1987.
  2536.  
  2537.      [3] We distinguish in the report between development of a backbone
  2538.          network providing gigabit capacity, the GB, and an
  2539.          interconnected set of high-speed networks providing high-
  2540.          bandwidth service to the user, the Gigabit Network (GN).
  2541.  
  2542.      [4] Incidentally, they already manage to serve 150 million
  2543.          subscribers in an 11-digit address-space (about 1:600 ratio).
  2544.          We have a 9.6-digit address-space and are running into troubles
  2545.          with much less than 100,000 users (less than 1:30,000 ratio).
  2546.  
  2547.  
  2548.  
  2549.  
  2550.  
  2551.  
  2552.  
  2553.  
  2554.  
  2555.  
  2556.  
  2557.  
  2558.  
  2559.  
  2560.  
  2561.  
  2562.  
  2563.  
  2564.  
  2565.  
  2566.  
  2567.  
  2568.  
  2569.  
  2570.  
  2571.  
  2572.  
  2573.  
  2574.  
  2575.  
  2576.  
  2577.  
  2578. Gigabit Working Group                                          [Page 46]
  2579.  
  2580.